Posts Tagged head
- Mode changes to init.rb, user updating to a newer version or Merb will need to add
c[:log_file] = Merb.root / "log" / "development.log"
to their init.rb file or config/environments/development.rb for instance. (Newly generated apps are already setup properly)
- We made some changes to the way Rake files work. Merb-core doesn’t require the rspec tasks anymore so Test::Unit see annoying rspec tasks. Once again people upgrading to the latest version of Merb need to make a small change and add:
to their rake file. Newly generated applications using RSpec already have that line setup.
- In the last few days, Yehuda merged in his branch with the new “request-testing feature”. This is a new way of testing your apps. It makes testing a real request going through a controller and being rendered in a view, something quite easy, Merb interegration tests here we go!. Check here to see a example of what you can now do. Rails + Rspec users might be surprised by this choice, and I’ve scheduled to interview Yehuda so he can explain why and when you want to use this way of testing your app. (Don’t miss his talk at MerbCamp next week)
- Talking about full stack testing, Merb is almost entirely full stack tested. What does that mean? Take a look at merb-helpers specs in merb-more. Form builders are tested through a real app available from spec/fixture/app, the views are rendered in the specs and the results are check to make sure they will work for you in your real application. Avoiding using too many mocks and stubs helped us really test things in the contet of a real app and avoid a great amount of ghost bugs. Specs might run a bit slower but we believe Merb now has better testing suite than before. More coming up about this topic.
- Ohh and we released Merb 0.9.8 “Time Machine”, last release before 1.0RC1
It’s hard to believe that in less that 20 days, Merb 1.0 will be released! We are all really happy to to be almost there but we have to be honest and admit that we are also under pressure.
We are all dreaming of a post 1.0 world but in the meantime we have to focus on last minutes bugs and optimization.
During the last week or so, we made a lot of progress, the API is now “almost” frozen and General Katz is focusing on making sure everything will be fine for D Day.
That reminds me that Katz showed me something amazing yesterday! I shouldn’t really talk about it but I’m sure it will stay between us. He was been working on optimizing the general memory consumption and my testing app (real app) went from 120MB of Private Memory used, to 70MB (using 4 processes). I can’t wait to use that on the field. I also hope my old Rails comrades will realize that running ~100Mb processes (x4) really isn’t efficient and event dangerous for the free Ruby world!
I also heard rumors that the higher officers are now using a new strategic tool called http://www.pivotaltracker.com which should help us streamline the process. We are still using LightHouse to track bugs and patches though. I’m not sure if this new “agile” tool will help, but I thought the approach is pretty interesting. What do you think?
You probably also saw my early report on bundling Merb apps, I’m quite happy about the process. Do you think you will deploy bundled/frozen apps or just use the system-wide gems?
Ohh before I forget, some courageous privates went to HEAD and use the 3rd party plugin called merb-auth. What they don’t know is that they need to change their routes to use the slices with the new router. (the new router requires no block variable) Also, if they look at the merb-auth branches they will notice a new mauth branch which is the new version of merb-auth, even better, more flexible than the previous version.
I hope everything is well for you, say Hi! to our friends for me.