You can check out the full code (the 500-line nanocode.py) here: https://github.com/owenthereal/build-your-own-coding-agent
I'm happy to answer questions about the 'Zero Magic' architecture or the decision to drop vector DBs.
316 karma · joined November 8, 2010
You can check out the full code (the 500-line nanocode.py) here: https://github.com/owenthereal/build-your-own-coding-agent
I'm happy to answer questions about the 'Zero Magic' architecture or the decision to drop vector DBs.
As a pragmatic approach, a half century of software engineering says that you should write the code first and worry about making it faster only if it is too slow. Donald Knuth is right: Premature optimization is the root of all evil. Don’t merely let the VM performance metric blind you to this fundamental truth. If you are chasing for a performing language, Java/Scala is not your ultimate solution, C/C++ is, even Erlang.
I actually don’t see a problem with “performance” emerging as the requirement in the Ruby world sooner than others, say Java/Scala, because this “sooner” is very contextual and depends a lot on the implementation. To give you more info, GitHub is on RoR since it started, and till now they haven’t hit the so-called “Rails does not scale” point ( http://teachmetocode.com/podca... ). So are many other projects. Besides, think about Twitter, they only recently try to port everything to the JVM, after Rails has served them a couple years. All these facts tell you, this “sooner” may never happen to your own app, and most importantly, Rails can scale, although it may not scale as well as others! But once you hit the point where Rails, or Ruby in general, doesn't meet your performance requirement (assuming you are lucky enough to build another Twitter), do what Twitter suggests you to do in the video. Is that too late? Not at all. Because by then, you have the resources to do whatever you want, even inventing a VM that is more performing than JVM.
To summarize, the Ruby VM was fast yesterday, is still fast today, and will be faster tomorrow. In 90% of the cases, it's just fast enough. Do I need the performance gain by switching to JVM? Don't know yet. It'd be better to let the market drive you. Does Rails provide the agility I want to start a project? 100% hell yeah!
Ideally, REST web service client test should have the following characteristics:
The experience of testing web service API is similar to that of testing a ActiveRecord model
Start up and shut down the web server for the purpose of running REST web services
Rollback test data after each test
Control fixture creation for REST web services
In this article, I demonstrate solutions to each of those mentioned with ActiveResource and Distributed Ruby.