This has to be one of the best book covers ever. You really have to focus on all the little details:
How the floppy disk is casually resting on the keyboard as if the coder had to leave in a hurry to do some coding else where.
How the books logo is stamped on the back of the leather jacket left behind on the chair.
I know I shouldn’t keep poking fun at some applications since I bet there is plenty people can find where I goofed up … but this one is truly precious.
When I write web apps I try my best to keep my urls clean and legible. One thing that has always troubled me is how to handle label creation of named things web users key into the app. For example if a user enters a name of a restaurant Alicanté Café the uri safe for of that (if there is no intervention) ‘Alicant%C3%A9%20Caf%C3%A9’, which is total gobblygoo and one might as well show a uid or something of that nature since at least that doesn’t physically hurt the eye. As someone who has worked on a lot of Restaurant related apps this has always been something I wanted there to be an easy solution to. This weekend I decided it was worth trying once again to see what would work best. And after reading the “Internationalization in Ruby” in The Ruby Way. Here is the super simple trick
require 'iconv'
strange_name = "Alicanté Café"
converter = Iconv.new('ASCII//TRANSLIT', 'UTF-8')
converter.iconv(strange_name)
"Alicant'e Caf'e"
It leaves some odd ’ and “sfor some reason but they will get stripped away with all the other potential weird stuff out (”,’,etc). Still this discovery makes me stop complaining about pretentious foreign sounding restaurant names.
Here is an excellent case of a big problem … with a incredible simple solution. I upgraded my slicehost ubunto vpn from dapper to hardy. A risky business with nothing real in jeopardy except for the pride of a 380 days up time on the server. I shut down everything running on the server and upgrade to hardy. All is fine except that I realize that when I am starting all the services that small things tab completion doesn’t work among other annoyances and doing work on a server without that is practically unbearable. So I figured I would make some time to fix it… the best place to go on these issues is slicehost … THE ROCK. Tony on the slicehost campfire chat immediately identified the problem and it was fixed within 5 minutes.
*Tony | try just running “bash”
And as he said that I was like shit and ran echo $SHELL only to realize that I was in “sh” but now everything is fixed and dandy and I have my tab completion back along with other normal bashy things … thank god. Did I mention that slicehost rocks!
Using AWS::S3
Now setting a object to :public_read is trivial if it’s done when you store it to S3. That doesn’t seem to be the case if you want to change on an object that already has been stored privately. After banging my head against it a bit I finally “got it” and I figured I would share it to either show off or try to be helpful.
dial into s3sh session see url above for details on how to store keys in environment variables etc.
once in there get a bucket object
now get the s3obj that you want to become public
The access control on the buckets must be very rich since it’s this tricky make things public. I must be overlooking something.
A while back I decided to get fancy and start hosting this blog on ec2 cloud just to sort of get the hang of working on that kind of a system. This of course involved moving database over and the works. Everything seemed to be going fine until I started posting… things were just busted bad. I kept getting
ActiveRecord::StatementInvalid (Mysql::Error: Duplicate entry ‘0’ for key 1
errors and for the longest time I just ignored it since I was able to post by using a some of my masterpiece drafts that I wasn’t going to use any how… but then I ran out of those and I felt an urge to post but that meant I needed to tackle the problem and as it turned out it was a simple fix after I had done the research. The primary key fields had lost the AUTO_INCREMENT magic during my db move and the solution was simply to go in and ad them where a appropriate.
ALTER TABLE `contents` CHANGE `id` `id` INT NOT NULL AUTO_INCREMENT;
Boy is that place a rats nest… haven’t looked at the site for a year now and decided to see how long it would take me to upgrade to rails 2. Remarkable enough it was really not that tricky to do which speaks to the level of my knowledge of rails at the time which was fairly slim so all my upgrading tasks where fairly light. So to make things more exciting I decided make it more rest-y … which also was remarkable light task except for a few minor issues such as lack of tests which makes it terribly difficult to even know if the site is working at all except for the fact that I clicked around a bit … (god I wish I had known testing better a year ago). So before I would dive into upping the test coverage I decided to save the very little traffic I get from google by issuing a 301 for the urls that changed. So as an former mod_rewrite ninja (oh did I mention that I deployed the site before I fell in love with nginx) I fired up .htaccess and wrote all the rules for the rewrites … then after 30 minutes of cursing and moaning I read somewhere that .htaccess doesn’t take on rails app jez. Not to worry I just stuffed the rules into my virtualhost config and things are flying.
Recent Comments