Sat 28 February, 2009
We have been advised of several vulnerabilities in the in_place_editing plugin which was created prior to the 2.0.0 release of Ruby on Rails.
- The actions generated by in_place_edit_for perform no verification of the request method, allowing a hostile website to bypass built in CSRF protection.
- The the input controls generated by in_place_editor_field perform no output sanitization, leaving the application vulnerable to XSS attacks.
Users of all versions of the plugin are advised to update to the latest version contained in our git repository at:
git://github.com/rails/in_place_editing.git
For users who are unable to use git, we have provided a zip file containing the patched code. The patch containing the fix is available also.
Users of all versions of Rails prior to 2.0 are advised to stop using the in_place_editing functionality, or manually apply those changes to their version of Rails. If these changes are backported, this post will be updated to include a patch for the relevant versions of rails.
Thanks to Pawel Stradomski of Code Sprinters for reporting this bug to us and working so patiently with us to get it resolved.
add to del.icio.us. look up in del.icio.us. 
add to furlI tweeted that I had a $50 Amazon gift card and asked what one book would people recommend.
If you didn’t, or don’t want to, reply to that tweet, post a comment here. In 140 characters if you can, too.
The list so far:
- Programming Clojure
- Hellboy Library Edition, Volume 1
- Beginning iPhone Development
- A Pattern Language: Towns, Buildings, Construction
- Agenda for a New Economy: From Phantom Wealth to Real Wealth
- JavaScript: The Good Parts
- Moneyball
- Cryptonomicon
- Eisenhorn (A Warhammer 40,000 Omnibus)
- Java Concurrency in Practice
- The Blind Side
- The Omnivore’s Dilemma
- Boyd: The Fighter Pilot Who Changed the Art of War
- The Snowball: Warren Buffett and the Business of Life
- The Algorithm Design Manual
- Alchemist
- Illusions
- Way of the Peaceful Warrior
add to del.icio.us. look up in del.icio.us. add to furlFebruary 14, 2009 – February 27, 2009
The sharp-eyed will notice that This Week covers two weeks this week. As Rails 2.3 approaches release, the core team is getting pickier about what goes into the source code, and is concentrating on fixing bugs. You can expect to see Rails 2.3 RC2 very soon, and that may be the last release candidate. So if you haven’t tested your own applications on Rails 2.3 yet, it’s time to do so. The edge code is generally stable right now, so it’s a great time to take a look.
Batch Processing
You can now process large numbers of records from an ActiveRecord model with less pressure on memory by using find_in_batches:
Customer.find_in_batches(:conditions => {:active => true}) do |customer_group|
customer_group.each { |customer| customer.update_account_balance! }
end
You can pass most of the find options into find_in_batches. However, you cannot specify the order that records will be returned in (they will always be returned in ascending order of primary key, which must be an integer), or use the :limit option. Instead, use the :batch_size option, which defaults to 1000, to set the number of records that will be returned in each batch.
The new each method provides a wrapper around find_in_batches that returns individual records, with the find itself being done in batches (of 1000 by default):
Customer.each do |customer|
customer.update_account_balance!
end
Note that you should only use this method when you have enough records to justify batch processing: for small numbers of records (less than 1000), you should just use the regular find methods with your own loop.
A Note About Template Loading
After some extensive work by several authors (here’s the Lighthouse ticket), Rails 2.3 includes the ability to enable or disable cached templates for any particular environment. Cached templates give you a speed boost because they don’t check for a new template file when they’re rendered – but they also mean that you can’t replace a template “on the fly” without restarting the server.
In most cases, you’ll want template caching to be turned on in production, which you can do by making a setting in your production.rb file:
config.action_view.cache_template_loading = true
This line will be generated for you by default in a new Rails 2.3 application. But please note: if you’ve upgraded from an older version of Rails, you won’t have this setting in your production.rb and template caching will be off by default. Unless you really need the ability to update templates in production without restarting the server, you should be sure to add this setting when you upgrade.
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlThu 26 February, 2009
23:03 撞了南墙好回头» 梦想风暴今天，Darwin和我接到客户公司另一个部门的邀请，同他们交流敏捷。
由于资源有限，我们只能投入到一个部门，所以，和我们交流的这个部门并没有我们的投入。他们几个负责人参加过我们先行的几个同事在这里所做培训，自己也从书上和网上了解了敏捷的一些理念和实践，另外，他们也和我们投入的部门进行的一些交流，并把一些成果引入到他们的团队中，比如单元测试的方案。他们的敏捷之旅就这样开始了。
看上去很美的一切，在真正投入到实践中之后，变成了种种的困惑和疑问。撞了南墙的他们选择了在今天找到了一个和我们交流。
“让我们把问题列一下吧！”，他们的负责人说。
“需求分析不完整”，“TDD不好做”，“单元测试框架不好用”，“Review大家都不愿意做”，“没有勇气做重构”，……
终于有了机会把憋了许久的怨气一下释放出来，大家你一句我一句，白板上一会就写满了各种各样的问题。一时间，空气中有一种剑拔弩张的氛围。
“首先，让我们放下敏捷，这些问题里面，有哪些是用你们原来的工作方式可以很好解决的。”，Darwin站在白板前问了这样一个问题。
“我觉得ST那条我们可以做好”，一个人指着其中一条ST测试不完整的问题说道，“我们原来都有很好的指导书。”
“那为什么不用原来的方式呢？”，Darwin问。
“不是要敏捷吗？”，这个人显然没有想到Darwin会问出这样的话，回答的口气明显没有刚刚那样强硬。
“OK，我们做敏捷，追求的是有效的工作方式，既然原来的方式很好，那我们继续做就好了。”，Darwin这样回答。
我坐在下面，暗自观察了其他人表情，刚刚那种准备挑战的表情明显开始转变了。
一个好的开头，让我们有了很好的讨论基础，于是，我们就着他们提出的问题一个一个进行解答。随着讨论逐渐的深入，我看见大家频频在那里点头，这也增强了我们的信心。
讨论的过程中，一个人说出了一个给我留下深刻印象的词，“伪敏捷”。在他看来，他们所做的只有敏捷的架子，而其他的一切还是按照旧有的套路。和我们的讨论，让他发现了很多彼此在考虑问题思路上的根本差异，这给了他们一个在日后改进工作打下了一个很好的基础。
后来，和Darwin聊天，我说，我喜欢这样有了一定基础的客户，他们自己尝试吃了亏，和我们交流时，才能真正体会到我们说的那些东西。
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlWed 25 February, 2009
That’s not actual code; I made that up.
Here’s something not made up: Stellar talent Daniel Davis has challenged me to present seven random facts about myself.
I’m not a fan of anything that smacks of a chain-letter, but Daniel rules so I’ll at least spew out some unneeded detail. (But I won’t be inflicting this on on seven other people. Feel free to take up the challenge on your own if you feel so inclined.)
0. Favorite color: Plaid
1. Born and raised on an island
2. First cat was named George Sand
3. First 45 RPM vinyl single bought: Frankenstein by Edgar Winter Group
4. Learned FORTRAN in college by coding cellular automata for a semester. Still do not understand how I passed the Numerical Analysis with FORTRAN course since, oddly enough, CA were not on any test or assignment.
5. Have never skied
6. Favorite movie is Metropolis, unless it’s Citizen Kane or Animal House
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlI’m amazed that Raganwald would have any trouble scoring work. Or the kind of work he would enjoy (since, in the broad view, its easy to get a job, less easy to get a job you enjoy)
Seriously, what are people thinking? “Oh, he seems smart, but he doesn’t have the .Net chops with BizTalk experience we need.”
I’ve been fortunate the work with many smart people. Most of them were good at what they did, i.e., their “real” job, but some also had a knack for helping others get better at their job, too.
It wasn’t just a matter of straight-up mentoring; these people were able to offer a different point of view, ask the odd question, get people thinking about new things in new ways. It kept things fresh, made the work more fun. It’s one thing to tell people stuff, it’s another to get people to want to know and understand more stuff.
Alan Kay said, “At PARC we had a slogan: ‘Point of view is worth 80 IQ points.’ “
Smart, interesting people like Reg should be hired simply to go wander around a company, strike up conversations, and ease people into a different point of view. It would make the whole company smarter.
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlGot something to? Something you’re passionate about? Can you you say it with 20 slides, 5 seconds a slide?
Ignite Phoenix III is coming up, and presentation proposals are now being accepted.
add to del.icio.us. look up in del.icio.us. add to furlPat Eyler has been asking some folks for their thoughts on the Merb/Rails merge. Basically, he’s putting the same three questions to a number of people, with interesting results.
He asked me, and has published my response.
BTW, the observation that adding Merb into Rails could mean that people will get to use Merb (or some form of it) while claiming to be doing Rails (and so avoiding the dread “but why use @foo? Why not Rails?” challenge) was copped from a post by David Koontz to the Phoenix Ruby User Group mailing list.
add to del.icio.us. look up in del.icio.us. add to furlMountainWest RubyConf is on March 13-14, 2009 in Salt Lake City, UT and costs just $100.
That’s right, perhaps the most kick-ass RubyConf of the year cost only one. Hundred. Dollars.
BTW, I’ll be speaking at the conference.
See the list of speakers here
add to del.icio.us. look up in del.icio.us. add to furlI forked the Monkeybars repo so I could safely experiment with some things. My repo is monkeybars-with-inline-ruby-swing and that’s pretty much it in a nutshell.
Often, when people talk about Monkeybars, they compare it to some other similar tool that uses inline code (often using a “builder”-style syntax) to define the UI. The typical Monkeybars demo, in contrast, shows the use of WYSIWYG UI editor to create a binary Java Swing class; this file is then used in the Monkeybars app.
Not surprisingly, showing how this is done can take some time, even for a basic Hello, World! demo app. The sad truth of conference talks and demos is that you can get screwed from both ends in trying to properly explain anything non-trivial. You want to point out the details (because your tool is powerful), but that eats up the limited time available. You also want to actually show something, ideally something complete, so you end up with something simplistic.
If done well, then everyone gets the point: robust, sophisticated tool presented in overly-simplistic app for demonstration purposes. However, you can often end up with people seeing it the other way: lots of detailed steps needed to get to skimpy results. What’s then not grasped (or not well explained) is that the details are there to convey the breadth of possibilities; the skimpy app is there to simply demonstrate that this is something real. You still have to apply some imagination to understand the implications for larger, far more complex applications by extrapolation.
Demos using hand-written code to define a GUI have a real edge here because the speaker never has to leave the code editor, never has to switch views or tools, never has to explain much more than “here’s some more Ruby.” What’s often not mentioned, though, is that the inline-style of GUI definition does not scale well beyond the typical demo program. What you see really is what your get. (Trust me; I would not want to have to work on JotBot hand-coding the UI.)
Of course, maybe you don’t want much more than a handful of buttons and some text fields. Maybe all you want is the desktop equivalent of HTML 3.2.
Sometimes that’s all I need for given screen in some larger app, and having Monkeybars provide this would make it that much sweeter. Best would be that it would not alter how one uses the full power of the library.
So here’s what my fork of Monkeybars adds:
- Some code to the base View class to aid in detecting when the Swing UI class is in fact created via Ruby, so that the appropriate reflection/meta-programming can be done
- An additional app generator that gives you an MVC tuple, with a basic view UI class, written in Ruby, in place.
Because I’m interested in getting people to play with this, I renamed the key files from monkeybars to jimpanzee. Now if you install the code as a gem you won’t stomp on any existing Monkeybars installation. (The code should be completely compatible with the current actual Monkeybars API, but the renaming is cleaner.)
With jimpanzee, you can do this:
james@james06:~/tmp$ jimpanzee MyCoolApp :demo
Creating directory MyCoolApp
Copying jimpanzee project structure
Creating default code for MyCoolApp ...
Final steps:
1. Place a copy of jruby-complete.jar in the MyCoolApp/lib/java directory
2. cd into the MyCoolApp/src directory
3. Run the code using jruby:
jruby main.rb
Happy hacking!
and if you follow those final instructions you’ll have a simple cross-platform GUI app running. Toss in rawr and you’re three steps away from having redistributable executables ready.
You can see it here (except for the Rawr part):
<object height='344' width='425'><param></param><param></param><embed src='http://www.youtube.com/v/u_g245nW_vg&color1=0xb1b1b1&color2=0xcfcfcf&hl=en&feature=player_embedded&fs=1' height='344' width='425'></embed></object>There’s more to be done, not the least of which is ensuring that my approach is robust. The generator needs improvement; it’s pretty brain-dead. (For example, :demo is a hard-coded flag for the generator code, and you can’t tell it what to name the generated tuple. But these are not difficult things to change. The real issue is what to change them to.)
There’s a certain “gee whiz” factor in this, because there’s a low limit on what such generators can buy you, and how much inline UI code you’ll want, but the flip side is that it does lower the barrier to entry, and it is of practical value when coupled with Monkeybars’ other killer features. The best part is that it is in addition to, not in place of, all the power the best GUI toolkit offers for creating robust GUI apps of all shapes and sizes.
Please keep in mind when you see any demo that looks a bit too good or too easy that maybe the cool comes with a cost. The most common is that what makes some things easy ends up making other things hard. Always try to ask the presenter what the limits are, if a tool will grow with you if the size your application expands, or if will you find yourself stuck once the gee whiz has worn off.
Whatever tools you pick, consider the long view.
add to del.icio.us. look up in del.icio.us. add to furlMonkeybars has a Kenai project now.
The code is staying at gitorius, but with Kenai we get some extras, such as a wiki, which is shaping up quite rapidly.
Also, InfoQ has an interview with me about Monkeybars reaching 1.0
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlSomewhat typical scenario at the monthly Phoenix Ruby user group meeting:
Some folks show up early. Some folks don’t know everyone else; we go around and do introductions. More people show up; not everyone knows everyone else; we do some introductions. And so on, until the meeting starts.
Introductions typically involved people saying something about where they worked, what they did, what their company was about, and so on. Even when you ask people to be fairly brief they often are not. Some folks just like to talk, mostly about themselves or what super cool awesome stuff they are doing. Fair enough, enthusiasm is important. And some folks get asked questions about their work during their introduction. Quite understandable; it’s good when you meet someone doing something you’re interested in.
The problem is that one or two digressions are OK, 15 or 20 are not. My friend Ray Niemeir, a regular at the PRUG, noted the problems with both repeated introductions and extended detail, and suggested ‘lean introductions.”
The idea is you go around the room, and each person says their name, and offers one terse bit of information pertaining to a given “tag”. We typically start off with “daytime affiliation” as the tag. With that constraint we can get through a good-sized group of people fairly quick. Quick enough that we can do again, and maybe again once more.
With each pass, the “tag” changes. “Favorite language other than Ruby.” “What you do for exercise.” “Last movie seen.” “Conference you really want to attend.”
My contribution to the technique was to ask each person to give their full name each time; I’m bad with names and the repetition really helps.
What’s nice about this approach is that it’s the right kind of simple. Easy to explain, easy to do, easy to vary when needed. If people show up late for the meeting, it’s simple to have another pass of lean introductions. Often (if I remember to do it) we’ll have another go-round at the end of the meeting (outroductions).
User group meetings are a great way to learn new technical information, but the big win is in fostering human relationships. The easier it is for people to start learning stuff about each other as people, the better. It means you can put a face to a name on a mailing list. I means you can better interpret the tone underlying list posts because you learn who’s serious, who’s a kidder, who’s who.
Lean introductions is great tool for community building; try it at your next user group!
add to del.icio.us. look up in del.icio.us. add to furlHappy Camper Studios has released what is, as best I can tell, the first commercial desktop application written in JRuby.
JotBot is time tracking done right. It aims to be minimally disruptive, but it uses a “pull” approach so that you don’t have to remember to go log your time. Instead, you get reminded at a configurable interval to record what you’ve been doing.
There’s a quick tour video on the JotBot home page that shows off most of the features and give you a feel for how it behaves.
I’m super proud of this release and the amazing work put in by my fellow campers, David Koontz and Logan Barnett.
You can read the back-story on the development process at David’s blog.
You can try JotBot for 30 days free, so give it a whirl.
add to del.icio.us. look up in del.icio.us. add to furlNow that JotBot has been released, I wanted to get more feedback for the application. I posted to Hacker News and solicited comments.
I have to say that I’m really pleased with the results. I’ve seen a jump in the number of people requesting trial keys; I can’t be sure (maybe Google Analytics can help me here) but I’m assuming the post prompted folks to try it out. So that’s good.
But the comments have been really useful. Not everyone is falling all over the app, of course. But there have been some good observations, some good questions about how JotBot works and how it effects the user.
I really appreciate the comments from Tony Wright of RescueTime. RescueTime was a Y Combinator startup, and I’ve been hearing good things about it ever since they launched.
Among other things, Tony’s comments made me realize that some may think of JotBot in terms of a productivity app, while others see it as a pro-active record-keeping tool. Hence, what works for some does not work for others, or work so well. (I, of course, secretly want it to be all things to all people. More realistically, I do not want to downplay its value as a productivity enhancer, but I do see how it differs from RescueTime and other “stealth” behavior tracking tools, and JotBot was born of a need to track activity details. Yes, it can make you more productive, but its “pull” model may be the wrong kind of disruption for some people. I just hope people try it before passing judgment)
Aside from Tony’s points, one comment really got me thinking: To use JotBot, you need a key, even for the free trial. For some, this is too much of an annoyance. Indeed, it would be much nicer if people could just download and run the app, while the time-limit still held. More thought needs to be given to that. I want it to be as painless as possible for people to see if JotBot works for them. On the other hand, I’m not a fan of crippleware or nagware. Suggestions welcome!
So, thanks again to the HN community. I’d love it if everyone who commented went and tried JotBot and then decided to buy it. But, no matter what, I’m really grateful that people take the time to offer their observations.
add to del.icio.us. look up in del.icio.us. add to furlBig props to Nick Sieger. His latest bit of super cool awesomeness is this :
As a result of some fruitful hacking at RubyConf 2008, I was able to modify JRuby so that gems can be loaded and used without having to unpack them. The feature became generally available with the 1.1.6 release last month. Gems in a jar!
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlWhile busy getting JotBot, our time-tracking tool , out the door, we (meaning Rising Tide Software and Happy Camper Studios) were not so attentive to certain pragmatic details. We lost work with one of our larger clients; they were bought, and the new owners put an end to new development.
So Logan and I are looking for Web development and desktop application development contract work.
If you have something, or know someone, please drop me a line or give me a call.
Contact info is here
add to del.icio.us. look up in del.icio.us. add to furlHappy Camper Studios and Rising Tide Software are to be no more.
Everything is being done amicably; this was a pragmatic choice based on business conditions. I would have preferred this journey had a different ending, but it was still a good and valuable trip.
I think the world of David and Logan and expect them to go to greater things.
While the Happy Campers were prime movers behind Monkeybars and Rawr, as individuals we will still be looking after them. We may not all have the same chance to use them in daily production work, so enhancements may be slower in coming. On the bright side, the code has reached a stable state, so they’re in good shape already.
Happy Camper also released the JotBot time-tracking tool. I’ll be looking after it now.
Go read what Logan has to say on the demise of RTS and HCS. It’s quite interesting, though I don’t agree with all he says.
In particular I disagree about having a partner. So far my experience is telling me that the magic number is two. It really helps to have someone else to bounce ides off of, someone who can cheer you on when you’re down, and vice versa. Sure, three people can do that, but for various reasons it gets unbalanced.
You really want to be sure that everybody gets to partake in discussions, but it’s not as easy with two other people to grab the phone or to pull someone aside when something pops into your mind. With each extra person there’s that extra bit of organizational friction, not in a personal sense, but in a physics lab “work and coefficient of friction” sense. You move a little slower, people get out of sync.
It’s speculation, though. There’s no way to know how any business would have been different with this or that organizational change. You can posit that there would be some difference, but not know if that difference would have been good or bad. (Excusing the pathological cases, of course.)
I’m reviving Neurogami as my consulting operation. I have some projects lined up, but I’m always interested in speaking to people about building things. Still hacking Ruby, plus working on Android apps, staying abreast of new tech, making stuff, and always looking ahead.
add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furl add to del.icio.us. look up in del.icio.us. add to furlMon 23 February, 2009
“ Earlier in my career I worked hard to attract attention. I consciously turned away from this pursuit because of the hollowness of achieving it and the cost. ”
Kent Beck
add to del.icio.us. look up in del.icio.us. add to furlSun 22 February, 2009
Despite my better judgement I now have a Twitter account. You can follow my wacky hijinks at http://twitter.com/pablotron.
I've also written a basic Jabber/Twitter relay called Joggle. I'm hoping to release it later this week. If you'd like to try Joggle now, you can grab it from the mercurial repository (you'll need Ruby, a spare Jabber account, and a few minutes to glance over the README file).
add to del.icio.us. look up in del.icio.us. add to furlI put together a new firewall and a new file server. The firewall is an ALIX 2d3 -- a tiny, low-power x86 SBC with onboard 3xLAN. The whole thing runs on 7-20V. Also, there's no heat sink ahe disk is compact flash, which means no moving parts!
The other machine is a new file server. It's replacing three older machines and a half-dozen Vservers. The hardware isn't as exotic as the ALIX, but I do have some pictures:
add to del.icio.us. look up in del.icio.us. add to furlI don't read Techmeme and you shouldn't either. But if you do, then this Greasemonkey script for Sean might come in handy:
A brief README file is also available. Basically the script allows you to hide articles by author. You can configure the filters using the two buttons in the top-right corner of the page.
add to del.icio.us. look up in del.icio.us. add to furlVersion 0.2.0 of ZipStream-PHP is out. The two changes are:
- Generated archives work with the Windows XP "compressed folder" feature.
- Dropped support for PHP 4.
Here are the relevant links:
- Download ZipStream-PHP 0.2.0 Tarball (Signature)
- ZipStream-PHP Bug Tracker
- ZipStream-PHP Mercurial Repository
As you can see from the link above, I'm using Redmine for bug and feature tracking. I've been using it for several months and it's fantastic.
add to del.icio.us. look up in del.icio.us. add to furlSat 21 February, 2009
add to del.icio.us. look up in del.icio.us. add to furl
{ |one, step, back| }
动态感觉 静观其变
Caiwangqin的blog
Articles published in Ruby Code & Style