Lately with work, I've been busy in some old school .NET 2.0. Until you work with something different, you never really realize how easy it is to do development in Perl. My top three reasons why I enjoy Perl over other languages:
1. Built-in complex data structures. I don't need to invoke, import, or compile any additional dependencies to gain lists, arrays, and associative arrays. This is big. Most Perl regulars don't appreciate their hashes and arrays until they are once or twice removed from the core. .NET has these data structures of course, but I have to be "using" the Collections namespace, instanstiate full blown objects, and deal with a lack of literal construct for them.
2. Transparency. Much like mst does and recommends, I, too, read the source code of modules before I use them to make sure they are inline with what I could consider good coding practices. This means when I have a problem or a bug with a module, the source to that module is really close at hand. This goes the same for what modules are considered "Core." If I believe there is a problem with how I am using a module, and the documentation is ambiguous, I can always pop open the .pm and figure out wtf is going on. This is much harder to do with the class library with .NET. Sure you can install a reflector and look at generated-from-the-bytecode source, but you lose quite bit of information doing that.
3. Platform choice. When we do Perl projects at work, we cover a pretty good spectrum of platforms. Some develop on OSX, I develop on Debian, and we've typically deployed to FreeBSD. Our codebase is typically git friendly, dependencies easily installed with cpanm. With .NET, I pretty much /have/ to develop on windows and deploy on windows and typically use something like svn, or TFS as a source code repository. Mono apologists need not comment. Oh sure you could whip out the cruisecontrol.NET and write your own pull scripts to pull shit out of git (with msysgit), but good luck getting that to fly with any customer that is in love with centralized source repositories and has a vested interest in maintaining them (TFS licenses aren't cheap). So what does that mean for me? It means dealing with the headache of doing development inside of a VM since I do not run windows on my machine for security and performance reasons.
Overall I prefer the development of projects in my beloved Perl. It doesn't mean I can't do development in other languages, I have bills to pay after all. It just means that I find the .NET environment to be rather limited and extremely monolithic. And good luck doing anything outside of the status quo, or poking at APIs that are rarely used. Down that path lies dragons.
Thursday, April 29, 2010
Monday, April 19, 2010
YAPC::NA
This year is going to be very different.
It seems that every talk that was submitted was accepted. I submitted five talks. I'm going to be rather busy this year.
Typically, in years, past, a single talk or maybe even two were selected when speakers would submit multiple. Also, there were a limited number of time slots for presentations. This limited the pool of speakers significantly and generally provided a great focus to the event.
This year, I worry that there will be an overwhelming amount of material presented.
So we will see. Luckily, a couple of my presentations are repeats from previous workshops this year. All in all, besides my concerns, I am extremely excited to see everyone. By far, this is my favorite time of year. Everyone comes out and shows off their awesome projects they've been working on.
Anyhow, next week, you'll see an update on Poke! The developer release went smooth, but I still have a lot of work to do in terms of docs and tests.
It seems that every talk that was submitted was accepted. I submitted five talks. I'm going to be rather busy this year.
Typically, in years, past, a single talk or maybe even two were selected when speakers would submit multiple. Also, there were a limited number of time slots for presentations. This limited the pool of speakers significantly and generally provided a great focus to the event.
This year, I worry that there will be an overwhelming amount of material presented.
So we will see. Luckily, a couple of my presentations are repeats from previous workshops this year. All in all, besides my concerns, I am extremely excited to see everyone. By far, this is my favorite time of year. Everyone comes out and shows off their awesome projects they've been working on.
Anyhow, next week, you'll see an update on Poke! The developer release went smooth, but I still have a lot of work to do in terms of docs and tests.
Friday, April 9, 2010
Rewriting POE::Component::Server::PSGI
So in following up with last post about TraitFor::Controller::Ping, I've been working on a monitoring framework and daemon. But today's post isn't about that, but about one of the sub components of that project, mainly the embedded HTTP server.
I discussed last that I wanted to make POE::Component::Server::PSGI a bit more resource conservative and basically pair it down from the POE::Component::Server::TCP it was using (which creates a new session for each socket connection), down to its constituent parts, mainly SocketFactory, and manage the ReadWrite creation myself. In my monitoring framework I want to display results via a little Web::Simple magic, but I want the app.psgi to take advantage of the frameworks tools to connect to the database and make use of the Schema class. I also wanted to save all of the work from having to open yet another database connection just for the web app. So how do I pass those structures along so the web app can use them?
It turns out that POE::Component::Server::PSGI doesn't really provide any means in which to hook into the process to provide any customizations. This is bad if you want to provide an application specific micro-framework to your web app. So I had no choice but to start working on a fork: POEx::Role::PSGIServer
First step in the process was to basically start over, but reference frodwith's logic as much as possible. To that end, I started with modern POE tools, mainly, POEx::Role::TCPServer which does exactly what I describe above: a single session managing a collection of wheels (including SocketFactory).
The PSGI specification also provides a mechanism for streaming content via a filehandle. And to support that mechanism, I wrote POEx::Role::Streaming, which will take as arguments, two file handles and stream from one to the other. This encapsulates the typical pattern of streaming and since it is a role, it is easy to consume and override with implementation specific details (which is required to support chunked transfer encoding).
Then there needed to be a lot more validation of parameters. So POEx::Types::PSGIServer was written to do some light validating on the various data structures passed around inside the role.
Lastly, I needed to split out as many of the closures as possible into real live methods so that I could either advise them or override them. Not only that, but also break up the larger pieces of code into smaller bite sized chunks to allow for maximum customization (ie, what to pass when converting the HTTP::Request into PSGI $env hash).
All of this is a net win. I am not quite finished yet, but you can take a look at what I have so far at at github: poex-role-psgiserver. Docs and tests will be written next. I'll probably cargo-cult frodwith's tests as much as possible to save some time. Expect a release very very soon.
Anyhow, a BIG thanks to frodwith for his work on POE::Component::Server::PSGI. Next time you see him, buy him an alcoholic beverage of your choice. I know I will.
I discussed last that I wanted to make POE::Component::Server::PSGI a bit more resource conservative and basically pair it down from the POE::Component::Server::TCP it was using (which creates a new session for each socket connection), down to its constituent parts, mainly SocketFactory, and manage the ReadWrite creation myself. In my monitoring framework I want to display results via a little Web::Simple magic, but I want the app.psgi to take advantage of the frameworks tools to connect to the database and make use of the Schema class. I also wanted to save all of the work from having to open yet another database connection just for the web app. So how do I pass those structures along so the web app can use them?
It turns out that POE::Component::Server::PSGI doesn't really provide any means in which to hook into the process to provide any customizations. This is bad if you want to provide an application specific micro-framework to your web app. So I had no choice but to start working on a fork: POEx::Role::PSGIServer
First step in the process was to basically start over, but reference frodwith's logic as much as possible. To that end, I started with modern POE tools, mainly, POEx::Role::TCPServer which does exactly what I describe above: a single session managing a collection of wheels (including SocketFactory).
The PSGI specification also provides a mechanism for streaming content via a filehandle. And to support that mechanism, I wrote POEx::Role::Streaming, which will take as arguments, two file handles and stream from one to the other. This encapsulates the typical pattern of streaming and since it is a role, it is easy to consume and override with implementation specific details (which is required to support chunked transfer encoding).
Then there needed to be a lot more validation of parameters. So POEx::Types::PSGIServer was written to do some light validating on the various data structures passed around inside the role.
Lastly, I needed to split out as many of the closures as possible into real live methods so that I could either advise them or override them. Not only that, but also break up the larger pieces of code into smaller bite sized chunks to allow for maximum customization (ie, what to pass when converting the HTTP::Request into PSGI $env hash).
All of this is a net win. I am not quite finished yet, but you can take a look at what I have so far at at github: poex-role-psgiserver. Docs and tests will be written next. I'll probably cargo-cult frodwith's tests as much as possible to save some time. Expect a release very very soon.
Anyhow, a BIG thanks to frodwith for his work on POE::Component::Server::PSGI. Next time you see him, buy him an alcoholic beverage of your choice. I know I will.
Subscribe to:
Posts (Atom)