[JOB] (mod_)Perl/Oracle Application Engineer positions in Portland, OR
++ Software Engineer Position(s) ++ ++ The eMarket Group (eMerchandise.com) ++ The eMarket Group (TeG) is a successful entertainment merchandise retailer. We focus on online and mail-order sales through our branded storefront http://www.eMerchandise.com and private-label storefronts for third party entertainment and media destinations. TeG is a private, independently financed company located in Portland, Oregon. We have recently achieved profitability and are growing rapidly. We have been named as one of the 100 fastest growing companies in Oregon by the Portland Business Journal. We currently have two software engineering positions available: ## POSITION 1: Application and Interface Engineer An application engineer working on general maintenance and development of our back-end systems with a focus on the human interface components of our internal business systems implemented in Perl PL/SQL. Maintain and enhance Oracle Forms based interfaces to back-end system components (product catalog management, warehouse management system, customer service and order processing, promotion management, procurement management). Evaluate and deploy alternative development framework to replace Oracle Forms, with desirable attributes being: platform independence, reliability, flexibility, maintainability. Evaluate and deploy customer contact management system (email, phone, chat, and mail contacts managed through consolidated system integrated with back-end orders and customers database). This may be an integration of a third party CRM system with our existing system or a development project to build contact management facilities into our core system. Buzzword/acronym compliance: - un*x (Solaris, Linux, *BSD) - General relational database, SQL, Oracle - Oracle PL/SQL - Oracle Developer Forms and Reports - General GUI Development - Perl, Apache/mod_perl ## POSITION 2: Application and Integration Engineer An application engineer working on general maintenance and development of our back-end systems with a focus on systems integration with our front-end web services and with external systems such as: freight manifesting, payment processing, supplier EDI and drop-shipping systems. Maintain and enhance existing systems in Perl and Oracle PL/SQL. Evaluate and deploy new integrated freight carrier compliance systems. Evaluate and deploy new payment processing system integration. Develop enhanced supply chain management capabilities. Buzzword/acronym compliance: - un*x (Solaris, Linux, *BSD) - General relational database, SQL, Oracle - Oracle PL/SQL - Perl - Apache, mod_perl - XML - EDI - Network protocols ## We are looking for smart and experienced people who have solid computer science and software engineering skills. Experience with the specific languages and environments listed above is desirable, but not essential. Degree desirable, but not nearly as important as experience. Good benefits, fun and flexible environment, equity participation. TeG is an equal-opportunity employer. Send resume or letter to: - email (preferred): [EMAIL PROTECTED] - phone: Alice Turtles 503-944-5044 -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | Some who do not wander are lost.
Re: GET request size
Alex Menendez wrote: is there any limit to the size of a GET request url when it is generated from inside a mod_perl module? I have a POST cgi coming in with a bunch of data and I would like to turn it into a GET url so I can effectively use lookup_uri and run from the Apache::SubRequest class. The W3C sorta leaves this up to the server. Here's an excerpt from the HTTP/1.1 spec ftp://ftp.isi.edu/in-notes/rfc2616.txt: The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. So, the answer is, "it depends." Try yours with a 100K URI and see if it barfs. I know GET urls have a size limit when they are initiated from a regular web client. Just wondering if the same is true when initiated from the server itself as a subrequest. Nope, the clients may impose a size limit. -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "Put 30 kids in a room with an easel, a computer, and a guitar. You'll get one Van Gogh, one Von Neumann, and one Van Halen. And 27 burger flippers."-- Damian Conway
Naked in URL (was Re: Templating System)
"Keith G. Murphy" wrote: Are there any browsers that do not actually handle the naked '' correctly? I confess that I also missed this, though I do understand the reason: the first one's invalid HTML. It just seems to always work. Think about this: A HREF="/somehandler?email=a%40xyz.comcopy=b%40xyz.com" vs: A HREF="/somehandler?email=a%40xyz.comamp;copy=b%40xyz.com" Is the copy in the first one the HTML entity for the copyright c-in-circle character or the query string argument seperater followed by an argument named 'copy'? Different browsers will make different interpretations depending on how well they adhere to the HTML spec, their known named entity list, and how hard they try to "do the right thing" with the erroneous naked ampersand. -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw
Re: mod_perl vs. FastCGI
Scott Thomason wrote: So, given that, here's the question again: why would you choose Apache::Registry over FastCGI? I want to be a believer... First, I don't really recommend Registry, if you're serious about your system you should use the direct handler interface and not just port a bunch of crufty old CGI scripts. Back in 96/97, I built an ecommerce engine using FastCGI Perl. Today my company runs its site on Apache/mod_perl. Both technologies address some similar concerns and are designed to reduce execution overhead and enable persistent application servers to communicate with and modify the behavior of web servers. FastCGI is a protocol for a web server to communicate with an application server over network sockets. It also includes some primitive process management facility, I believe. mod_perl is an in-process integration of the Perl interpreter with the Apache web server. When I was using FastCGI, mod_perl was relatively immature. FastCGI worked but also was suffering from the support abandonment of its inventor Open Market. We had to debug several problems with the open source FastCGI code in our environment and there was relatively little support. But we got it to work, and it did work well in production. When we set out to implement our second generation ecommerce engine, we re-evaluated and choose to use mod_perl primarily because it had accumulated a vastly larger user base, resulting in a more mature environment and far superior support resources. I still think this is mod_perl's chief advantage over FastCGI. I've never worried over-much about porting old CGI scripts to either environment so can't speak to either technology's efficacy for this use. FastCGI pros: Web-server independant Language independant mod_perl pros: Larger user base, more real-world implementations More extensive support infrastruction: the guide, this list, etc. Extensive library of modular extensions which have been designed and tested to be used in the mod_perl environment Greater web server integration -- 14 handler hooks for mod_perl: PerlChildInitHandler PerlPostReadRequestHandler PerlInitHandler PerlTransHandler PerlHeaderParserHandler PerlAccessHandler PerlAuthenHandler PerlAuthzHandler PerlTypeHandler PerlFixupHandler PerlHandler PerlLogHandler PerlCleanupHandler PerlChildExitHandler vs 3 server hooks for FastCGI: Responder Authorizer Filter Which one to use should depend on what your needs and experience are. Properly tuned implementations of either will have very similar performance and resource utilization characteristics. -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "Forrester Research projects that by 2003, Internet start-ups will have focused so relentlessly on infrastructure that there will be no remaining actual content on the Web. " -- Salon.com 14-Apr-2000
Re: Apache::GzipChain and scalability
Bruce Lo wrote: I tried out Apache::GzipChain for dynamic mod_perl pages (using Apache::Registry), and it was great for reducing the download time (especially over modem). I am seriously thinking about using it for our production environment. However, some people are concerned about it using up too much resource. Has anyone looked into scalability issues? Would I see significant reduced throughput using GzipChain? We've been gzipping for a while at eMerchandise.com (though not using gzip chain). We addressed this issue by making the gzip pass decide whether to just pass it through or to do the compression based on current CPU load on the server. So when you've got extra cycles you shrink the file to improve bandwidth utilization, if you're running near peak processor utilization you send the bytes raw. We've had no scaling problems. What kind of system load do your production server(s) see now? What is it during peak traffic periods? Also why don't most sites gzip their pages (do redirect based on browser support)? Because they're lazy or stupid? :) -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "Forrester Research projects that by 2003, Internet start-ups will have focused so relentlessly on infrastructure that there will be no remaining actual content on the Web. " -- Salon.com 14-Apr-2000
Re: [OT] anchoring regexp
"J. Horner" wrote:
On Mon, 10 Apr 2000, Jason Simms wrote:
As to your problem, I doubt people can be of much assistance (though we'll
see) without seeing the regex and sample data. Perhaps if you resent that??
In any case, good luck. And perhaps, stay in touch, or put me on a mailing
list, or something. Thanks!
You have a good point. Sorry about the lack of code.
Here is my analyzer_benchmark script that will show you the code.
$ diff first anchored
1c1
sub first {
---
sub anchored {
9a10
my $request = join(" ",$method,$uri);
The only difference between your two benchmark subroutines are their
names, and that the anchored one also composes your $request variable.
Of course anchored will take a little longer -- it has one extra
statement.
--
Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED]
The eMarket Group | eMerchandise.com | http://www.eMerchandise.com
503/944-5044 x228 |
"Where do you want to go today?"
"Confutatis maledictis, flammis acribus addictis"
(The damned and accursed are convicted to the flames of hell)
Re: [OT] anchoring regexp
"J. Horner" wrote: Sorry, it is a Monday. I attached the right file. -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "Where do you want to go today?" "Confutatis maledictis, flammis acribus addictis" (The damned and accursed are convicted to the flames of hell)
Re: [OT] anchoring regexp
"J. Horner" wrote:
Sorry, it is a Monday. I attached the right file.
You're problem is that you have toomuch other junk in addition to the
statements you're trying to compare. Also, the strings you're matching
against are all so short that you wont see much difference between an
anchored and unanchored regex.
If you want to see the timing advantage demonstrated, try something like
this instead:
use Benchmark;
my $iter = 1;
my $listsize = 100;
my @internals = ();
sub make_rand_str (;$) {
my $maxstr = shift || 200;
my $str = '';
for (1 .. int(rand($maxstr)+1)) {
$str .= chr( ord(' ') + int(rand(127-ord(' '))) );
}
return $str;
}
for (1 .. $listsize) { push @internals, make_rand_str(); }
sub unanchored { grep { /134\.167/ } @internals; }
sub anchored { grep { /^134\.167/ } @internals; }
timethese($iter, { unanchored = 'unanchored()', anchored =
'anchored()', });
--
Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED]
The eMarket Group | eMerchandise.com | http://www.eMerchandise.com
503/944-5044 x228 |
"Where do you want to go today?"
"Confutatis maledictis, flammis acribus addictis"
(The damned and accursed are convicted to the flames of hell)
