The New York Times on Bucharest's Flourishing Housing Market, a load of bullocks.
Don't be fooled while it may be the Europe's sixth largest city I doubt that there is one more ugly. Dirt everywhere, historic center in ruins (ill maintained buildings are the norm as clearly visible in the front picture), danger of stray dogs (a year ago they bitten to death a Japanese businessman), very little and continuously shrinking green space, horrendous architecture legacy of the communist times.
I've only spent 3-4 pleasant hours in Bucharest, while dancing and savoring fine Romanian red wine: so it does not count.
All of the pictures where shot from inside the apartments vs actual places from the city. And the article is filled with the mambo-bambos of a real estate agent mixing the term "need" with the word "demand". They thrive on housing bubbles! City with a lot of potential ... absolutely true, but it does not show much journalistic objectivity to have its current state be hinted by so poorly.
Regardless if you are an a beginner or an expert with dozen rails projects under your belt you should really appreciate the posts at Ruby on Rails Security blog. The devil hides in the details that are all to often overlooked. True the recommendations shared are not rails specific, they are applicable to any other web stack.
One interesting recommendation that caught my eye was having a separate user for running migrations. The reason for this is simple: you don't want a malicious user to inject an drop table users or some similar nastiness in your application. Sure you can avoid SQL injection by restrain yourself to proper query construction Rails or use exclusively the intuitive find_by_ methods. If you feel uncomfortable with the assumption that the entire codebase will never have an improper construction, better add one additional security measure: have a custom user just for database migrations, and not allowing the rails production user to drop tables.
Whilst rails does not set up your project with a custom migration user, it is quite simple to tweak support for this into a rails project. Basically you need to add a custom environment just for database migrations. First lets create a user that can do schema edits, lets call it "app_migrator". This is specific to your RDBMS flavor, and will not document here: use the manual.
Next add a migration entry to your database.yml file. Something simple like:
migration:
adapter: mysql
database: app_prod
username: app_migrator
password: the_secret_password_goes_here
Note that the database is the same as the one you use for production environment, just the authentication info changes.
Rails will try to load config/environments/RAILS_ENV.rb during its initialization process, next step is to add this file. For our purpose an empty file will suffice:
$touch config/environments/migration.rb
Now lets do a quick test to confirm that all works well:
$script/console migration
Loading migration environment.
>> User
=> User
I've started the console in the "migration" environment and behold it worked! Now tweak the capistrano deploy script. You want to perform the migration within the newly created custom environment. Start by overloading the standard migrate task in your conf/deploy.rb:
task :migrate, :roles => [:db] do
run "cd #{release_path} && rake db:migrate RAILS_ENV=migrate"
end
Commit your changes and enjoy!
Disclaimer: Security comes in layers and not by a single measure. By following the above recipe you will not gain full protection against sql injections.
Technorati tags: Rails, Security
YAML.load(unsafe_json.gsub(/,"(\w+)"/, ', "\1"').gsub(/"(\w+)":/, '"\1": '))
Technorati tags: YAML, JSON, Ruby, Javascript
My one and only Eszter, Thank You!
A freshly printed book with original list price of $52, is being offered as used book for the Low Price of $449. All this from a reputable seller with flawless rating for the last year. Other sellers ask 490$ or even $1229 for the same item. Yes you've read that right: the used version is sold at ten or up to twenty times more.
Book in question was authored by Paul Graham of Y Combinator fame and it's about Lisp. A language invented and mostly ignored for 50 years. So how does On Lisp, an otherwise freely available book ends up with a price tag a magnitude higher than its list price? Simple it is no longer printed by its publisher Prentice Hall). There is just no market big enough for to make it worthwhile for them printing it. In fact renowned book publishers like O'Reilly downright disregard book proposals for the simple reason of being about Lisp. Mind you this is not a rumor its a fact! They proudly display for the public in their Proposing a book guideline.
I doubt that there are potential buyers of On Lisp who don't know that it can be simply downloaded. Other Lisp classics are also freely available. Yet people are selling it for multiple of its list price. This is a place where large book publishers cannot enter while the used book sellers can act freely. Sure they will not get rich by selling one book. Probably they will regret the transaction on the next day: its a great book you know! But the principle still applies: they have found a way to compete by not competing.
About two years ago I worked for a company claiming to be the one employing the most computer programmers in the world. Doesn't matter how did they counted this, or if this is something to be proud of in the first place. I do know that most of my peers, with whom, I graduated are still employed by the same uber conglomerate. Even younger graduates work for the same company, or are under employment of similar large empires.
There seems to be a prevalent image that to be successful one must work for The GigaCorps: large multinational whatever. They appear as safe, professional and ultimately elite places to be. Greatness is first measured by project size then in number of subordinates. More the better. Professionalism is measured in ISO certifications, CMM scales or lately the CMMI appraisals. Higher rankings the better. Programmer market value is measured on enterprise buzzword compliance. More matches the better. Amongst all the most fundamental aspect of happiness is lost.
The problem is competing itself: to win you should not compete with them at all. They are faceless entities lacking personality. Everything that an individual is not. So why compete with them? Let them squabble in battle grounds they dominate. You should use different smart approaches that are impossible for them to follow. And I don't mean impossible for the market being too small, rather their modus operandi would not allow it.
Why is it that all of these GigaCorps require basically the same skill-set? They need a commodity resource, something that while it may not be the best tool for the job, it does offer the safety of a more plentiful resource. Why will they spend a half fortune on building their next multithreaded gizmo using Java/.Net/C++? Why not something potentially more appropriate like Erlang? Again it's simpler and safer for them to rely on a more plentiful resource, even at the expense of suitability.
Why do they need expensive CMMI approval certificates? CMMI is something they can more or less buy while the small smart competitor can not. They can exchange money in a most accessible way for bureaucrats, to purchase differentiators. Why do they have a permanent need to increase the head count? Partly it's their manufacturing legacy where more machines(people) mean greater output. But there is also healthy doze of ego cherishing involved, they love to build Organigrams. Above a certain size some mechanics are proud of adding an extra cog.
Here is my tip to compete by non-competing: take pretty much every metric (except the truly essentials like customer satisfaction, reach, personal satisfaction, profit etc) the large company boasts about and just let them win. Now find different ways, ones that they can not imitate. Pretty simple since they are all too similar, but quite hard since they have by far more money to spend than you do. Once you have found it just focus on doing a better job. Rinse and repeat.
And if you know what I'm talking about consider finding a job where you can learn and experience this cultural difference. Where you can be happy in the process! Write us at job at primalgrasp dot com. Right now we are a Ruby&Rails shop, this should delight you. But we keep our minds open and look for better ways: this should delight you even more. Join us!
Technorati tags: ramblings, Rails, Ruby, Erlang, Lisp.
“cheap, fast and reliable” pick two and you might get an usefull answer.
Don't keep the user waiting while your favorite Javascript library are streamed down the wire. Keep the download small and your users will thank you for it! All you need is a simple snippet inside your lighttpd.conf file:
# this assumes that mod_compress is loaded
compress.cache-dir = "/var/lighttpd/cache/compress/"
compress.filetype = ("text/plain",
"text/html",
"text/javascript",
"text/css",
"application/xml")
That's all folks! Without fussing with risky source altering Javascript compressors. Just let lighttpd gzip the content before transmitting over to the browser. Some results for the Javascript files shipped with rails:
| File | Size in bytes | Compressed |
| prototype.js | 55149 | 12466 |
| effects.js | 32871 | 7278 |
| controls.js | 28036 | 7246 |
| dragdrop.js | 29435 | 7112 |
did I say that it works on styleseets too?
Just thought I share a small tip from the tranches, while working on Harvest a terribly useful timetracking application!
Tabs with CSS background images set appeared to flicker annoyingly whenever on mouse hoover. This affected only IE, guess this is not a surprise after all the oddities one must face with this browser. Also it only annoys users with their browser cache set to ""Every visit to page". Typically these are webdevelopers, end-users rarely have this setting on. Numerous solutions exist, an see excellent description by Ryan Carver.
Fixing this with lighttpd is quite simple, just add the following lines to your lighttpd.conf file:
expire.url = ( "/images/" => "access 1 hours",
"/javascripts/" => "access 1 hours",
"/stylesheets/" => "access 1 hours")
Got to love the new trend tool from Google. With a clear simple interface, gives you access to all nifty statistics about search keyword volume. The value might not be obvious on first site, well at least it wasn't for me, but it definitely pays of the time spent experimenting.
Technical person as I'm first tried some programming language searches. The O'Reilly radar already published interesting trends about the computer book market so why not put these to the test.
A quick search for: for JavaIt is confirmed Java appears to loose ground. The slowly fading but still enterprisy J2EE: enterprisy J2EE while speaking about enterprise .Net looks stable.
The generally frowned upon, 'wont scale' PHP appears somewhat decreasing.
Subversive Ruby base for the much hyped Ruby On Rails framework seems slowly ascending. Probably the term 'ruby' is just too general for now and we see more noise than our bellowed language. Google associates news titles to the keyword and they look mostly unrelated. Ruby On Rails has much better name with less false positives: steep and radical growth , unfortunately such rate has its own side effects but solutions exist.
All of them charted in one graph for comparison. Java dominates, followed by PHP, then .Net with J2ee and Rails looking like insignificant dwarfs. Just to see how small Rails is compare it the the once dominant "business" language COBOL or to Lisp an unjustly neglected language.
So where should You invest in your knowledge portfolio. Certainly not Java, I would rather take any other blip on the radar screen. You see these trend maps cannot be read just as market need, rather simply the number of players in each market, that is greater competition. My advice is simple chose what you love, since you'll not stand a chance otherwise against those who do.
For a better career advice you should read Chad Fowler's enlightened book. One interesting theory from it is that a western developer can compete on the global market by explicitly searching for lesser known, but higher yield fields. Oversimplified this goes like this: since there are insignificantly few Lisp, Python, Ruby, Smalltalk, (...) developers in India, you will not have compete against their lower rates.
BTW Google trends has nice feature of showing top cities, regions and languages for a given keyword. Do mind that these are normalized, but even like this should put some perspective on the strong competition at lower rates from main outsourcing destinations. Of course all mainstream languages have strong comparative foothold in India. Even previously fashionable ones like COBOL. In the end languages are commodities, basing your future solely on them is less than advisable.
Technorati tags: Rails, Ruby, Java, .Net, PHP
Posted a small update here.
On one hand you need to reduce risks, on the other you need to expand your horizon. Both should be constant activities, if you engage in the first only you’ll stagnate, certainly reducing your market value in the long run. If you opt for the second only, your short term value will fluctuate wildly. My advice is to learn just for the sake of learning ! Then if you’ll opt for something different the effort would be still well spent: you have gained an broadened understanding.
Wonder how this commercial was made?
I almost see the creator basking at a beautiful and crisp Macintosh trying to make a dull machine into something attractive. Then in a spur of the moment she gets creative and takes a screenshoot of her own desktop. Exercises her graphics program and paints it over that undesirably monotone blue screen still visible on the original picture!
Don't ever be ashamed to need an IDE or to ask for one. Of course, there are bad ways to use an IDE (e.g. you want code generated for you) but if you are interested in Ruby on Rails, chances are that you are a decent developer and you know how to leverage an IDE to make you more productive than when using emacs. Code completion or navigation, debugging, refactoring, project management, source control integration, etc... there are too many features to list that make you more productive if you use a tool that enables them.<br \> This is 2006, not 1996. The programs we are writing and the problems we are solving every day are orders of magnitude harder than back then, and our tools need to keep up with that need. Emacs is a fine text editor, but it's no longer adequate for modern development.
Boy you are so wrong. I challenge any IDE master, try being half as productive then a properly configured Emacs, in the hands of an knower. Obsolete? You must be joking: Emacs is the reference point. Do check on your beloved Eclipse, how do you save a file? Where do you think C-X C-S came from? Or the MS Studio/Jbuilder/whatever has key bindings of which editor?
What about code completion, who said that Editor MACroS cant do it? Class browser navigation its overrated, normally you just want to jump from function call to a body and back. A task perfectly performed by Emacs (or vim for that matter). Debugging? Use automated test suites, read your code instead of staring pointlessly at a debugger. But hey you can use gdb, rdb, jdb, or whatever else with Emacs trough the Grand Unified Debugger.
Refactoring? Perhaps the argument has some weight with a language like Java but definitely not for Ruby. Project management? Well if you like to complicate things there is EDE but I did not found need for it while working with RoR. Source control integration? Emacs has it period.
This list and the Ruby/Rails community have been a great valuable resource to me, so I'll bite. Considering I don't know you and your friend and no-one has vouched for you, I'm not entirely comfortable sharing a room with you. My two-year old son would probably frown on it if I came home in body bag. (My wife on the hand would reap a nice windfall in insurance proceeds, so she may feel differently.) At any rate, contact me offline and I'll pay for a separate hotel room for you and your friend (I like my space). But, I'm not buying you drinks, okay.
HaloScan provides a free, easy to use commenting and trackback service for weblogs and websites, allowing visitors to leave feedback, share their opinion, or comment on the subject at hand.
Nicely put no? Gives you that warmth feeling of reassurance that this is "free service". Well for once if you claim to be something better be that something. And if there are interpretable items better address them in in clear and visible manner. The Signup page would be good candidate, the Terms of Service page will suffice, or perhaps the Comments Faq page?
Apparently Haloscan did not think so. And while I fully understand that somebody has to pay for my "free" enjoyment, I'm less sympathetic with aggressive tactics to squeeze your users. That's how I felt when after a year of happy usage, I realized the reason why old comments kept on disappearing from my blog. You see Haloscan will "archive" your comments after four months.
A policy certainly not advertised on their front page, not showing comments older than four months does not sound like "Free Commenting" at all. Archived? How about inaccessible to everyone till I upgrade my account. Talk about honest business practices.
They also have an "Export" feature, the kind you implement for your users to feel a clear message: you are not using a closed system, you can leave us at any time, no harm done, data is yours. Reasonable? Again apparently not, since I need an upgraded account or else export is just teaser menu-item. Where is my clear opt-out?
To top it off they have a donate page, that clearly explains the advantages of becoming a "premium" member, without detailing the disadvantages of not doing so.
Bits and pieces about Me glued together by Me!
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- (Subscribe to this page via RSS!)