I've been making this morning train commute for months... but the view of the Catskills reflecting on the Hudson in the early morning just never gets old (taken with my iPhone through an Amtrak window).
Monday, March 8, 2010
Tuesday, February 2, 2010
die ie6, die
Just got my notice from Google Apps, that they will be phasing out support for IE6 during 2010. Google Docs on March 1st, Gmail and Google Calendar later in the year.
Will this finally be the year?
Will this finally be the year?
Wednesday, January 6, 2010
ruby collaboration
Towards the end of 09, I began a new adventure in the book of Scott; I started looking for Ruby work in Manhattan. That in itself might not sound all that radical. But, when you factor in the point that I live in Albany NY, a whopping 2.5 hour commute each way, you start to get a feel for why many people think I'm nuts. Additionally, when you factor in the daily cost for a train (or a place to stay during the week), it means that I'm making significantly less money then I have in the past 5 years. The radical becomes extreme.
So, the question is why?
For the past few years, I've been working primarily with Ruby. I like to think that I'm pretty good at it. When I first started toying with Ruby in 2005 it was a fun little hobby. Then it turned into side projects, and then eventually my full-time development language. But, in order to make this switch, I've had to do a lot of "one man" development work. There hasn't been a lot of daily collaboration with other Rubyist. Yes, I try to go to a few conferences, read books, follow blogs, stay engaged with both my local Ruby community and the community at large, contribute a few patches to open source, etc. I've had a little collaboration via IM, Skype, etc., and with part-time employees at my recent start-up, but not much chance for face to face, or pairing with other Ruby folks.
Yesterday, I got to do some pairing for a couple of hours with the RubyHead. Today, I hope to collaborate with him and a few other smart Ruby folks a little more. Over the next few weeks and months, I look forward to the team and environment we will continue to foster, and the daily collaboration with other Rubyist.
Thats why.
So, the question is why?
For the past few years, I've been working primarily with Ruby. I like to think that I'm pretty good at it. When I first started toying with Ruby in 2005 it was a fun little hobby. Then it turned into side projects, and then eventually my full-time development language. But, in order to make this switch, I've had to do a lot of "one man" development work. There hasn't been a lot of daily collaboration with other Rubyist. Yes, I try to go to a few conferences, read books, follow blogs, stay engaged with both my local Ruby community and the community at large, contribute a few patches to open source, etc. I've had a little collaboration via IM, Skype, etc., and with part-time employees at my recent start-up, but not much chance for face to face, or pairing with other Ruby folks.
Yesterday, I got to do some pairing for a couple of hours with the RubyHead. Today, I hope to collaborate with him and a few other smart Ruby folks a little more. Over the next few weeks and months, I look forward to the team and environment we will continue to foster, and the daily collaboration with other Rubyist.
Thats why.
Tuesday, September 22, 2009
Google Chrome Frame
Ok, this just looks fun:
http://blog.chromium.org/2009/09/introducing-google-chrome-frame.html
Allow your IE users to experience HTML 5 and faster Javascript rendering, by running your IE users inside Webkit via a Google Chrome Frame.
Prompt your IE users to install Google Code Frame plugin, then add a single meta tag to your pages, and... hello Chrome inside IE.
I don't know how "real world useful" it will be, because the people running IE 6 are probably not people that can or will install something like Google Chrome Frame.
But the idea is freaking cool. A little devilish, but very, very cool.
I'll have to check this one out a bit further.
http://blog.chromium.org/2009/09/introducing-google-chrome-frame.html
Allow your IE users to experience HTML 5 and faster Javascript rendering, by running your IE users inside Webkit via a Google Chrome Frame.
Prompt your IE users to install Google Code Frame plugin, then add a single meta tag to your pages, and... hello Chrome inside IE.
I don't know how "real world useful" it will be, because the people running IE 6 are probably not people that can or will install something like Google Chrome Frame.
But the idea is freaking cool. A little devilish, but very, very cool.
I'll have to check this one out a bit further.
Thursday, August 27, 2009
TCBTB show in Albany
The Cast Before The Break will be playing at the Red Square in Albany this Sunday night (8/30), and I can't wait!!!
If you haven't seen these guys live, you are missing a real treat. The last time they played here the show, audience and venue were fantastic!
Their latest release, Still has received very favorable reviews at both:
Man, this is going to be fun.
Monday, August 24, 2009
Not quite an empty nest
Hard to believe, but this will be the first year in the past 17 that I don't have a child in the k-12 school system. We moved our middle child out to college yesterday, and we bring my baby out to school on Friday. My mom always told me that I'd be surprised how fast it goes by, but until you are at a point that you can look back on it yourself you really have no idea.
However, its not all empty nest parties yet. My oldest finished college last year and is now back home as he tries his hand at the starving artist thing. But its hard to believe that my days of shouting "Anybody need help with homework tonight" are behind me.
As I got thinking about how different things are for me this year, it got me thinking about how crazy some of the times have been over the past 17. Between homework, morning shower coordination, and careers we have had our hands full. Maybe it only feels like those years went by so quick because we were always so busy!
Anyway, as I go thinking about the things we have done over the years to keep everyone on the same page in my house, and efforts to have "family discussions", I got thinking about what a great tool iZoca can be for families. While we promote iZoca for professionals, groups and organizations, it doesn't mean that it isn't also a great way for families to stay organized and connected and do it all with a little more privacy then they probably associate usually with social networking.
I wrote about these thoughts over on the iZoca blog.
Monday, July 27, 2009
mongrel_cluster, Rails 2.3.x, bad post, routing recognition
There is currently a problem running mongrel_cluster against a Rails 2.3.x application. The odd thing is that the problem only occurs when the first request to a newly started mongrel is a HTTP Post and not a HTTP GET. If the first request is a GET then it is handled fine, and all subsequent POST and GET are fine. But if the first hit to the Mongrel is a POST then bad things happen.
What kind of bad things? How about no form parameters or session parameters set by the time the request makes it to the controller bad.
However, because the problem only happens if the first thing that hits a freshly started mongrel withing a mongrel_cluster is a POST, it can be a bit of a tough one to track down.
We first started seeing this as an occasional "routing recognition problem" that we had a devil of a time with. We all know about the _method hidden field added to Rails forms so that the controller can think that a HTTP PUT or HTTP DELETE was made, when really its POST with a hidden field. Unfortunately (or fortunately I suppose because it was the impetus to track this down), the URL recognition gets messed up when the action field is missing.
For example, if you are POSTing to /some_url/resource/1 with an _method of Delete, Rails wires that up to look like an HTTP DELETE, and wires it up accordingly in your controller. But, if the _method field is missing, then we have a POST to a resource, which is really expected to only ever be a GET....and bam the dreaded
"A ActionController::MethodNotAllowed occurred in application#index:
Only get, put, and delete requests are allowed."
When Rails is started via ./scrip/server and Mongrel is installed, Rails will use the new Mongrel handler which is designed for 2.3+ applications. However, when the Mongrels are started via mognrel_cluster the old cgi type of mongrel_handler is used, which I learned from finding this post:
http://www.timocracy.com/2009/04/15/problems-with-mongrel_cluster-and-rails-2-3-dispatcher-reloading-your-metal-every-request
We are currently investigating the benefits and options of moving our Rails 2.3 version of iZoca to either a Passenger based solution, or configuring some Rackup Mongrel instances. One of my concerns going forward will be that we don't make it more difficult down the road to introduce some Rack based middleware or even some Metal where appropriate. I don't think either of these solutions will make that task more or less difficult. We'll be doing some testing and benchmarking on both options.
What kind of bad things? How about no form parameters or session parameters set by the time the request makes it to the controller bad.
However, because the problem only happens if the first thing that hits a freshly started mongrel withing a mongrel_cluster is a POST, it can be a bit of a tough one to track down.
We first started seeing this as an occasional "routing recognition problem" that we had a devil of a time with. We all know about the _method hidden field added to Rails forms so that the controller can think that a HTTP PUT or HTTP DELETE was made, when really its POST with a hidden field. Unfortunately (or fortunately I suppose because it was the impetus to track this down), the URL recognition gets messed up when the action field is missing.
For example, if you are POSTing to /some_url/resource/1 with an _method of Delete, Rails wires that up to look like an HTTP DELETE, and wires it up accordingly in your controller. But, if the _method field is missing, then we have a POST to a resource, which is really expected to only ever be a GET....and bam the dreaded
"A ActionController::MethodNotAllowed occurred in application#index:
Only get, put, and delete requests are allowed."
When Rails is started via ./scrip/server and Mongrel is installed, Rails will use the new Mongrel handler which is designed for 2.3+ applications. However, when the Mongrels are started via mognrel_cluster the old cgi type of mongrel_handler is used, which I learned from finding this post:
http://www.timocracy.com/2009/04/15/problems-with-mongrel_cluster-and-rails-2-3-dispatcher-reloading-your-metal-every-request
Then, it looks like there is a problem with the "first" HTTP Request being a POST when going through the older cgi Mongrel handler. Which looks like it is already covered in this ticket:
We are currently investigating the benefits and options of moving our Rails 2.3 version of iZoca to either a Passenger based solution, or configuring some Rackup Mongrel instances. One of my concerns going forward will be that we don't make it more difficult down the road to introduce some Rack based middleware or even some Metal where appropriate. I don't think either of these solutions will make that task more or less difficult. We'll be doing some testing and benchmarking on both options.
Subscribe to:
Posts (Atom)


