The recent launch of Logpost motivated me to build my own API-driven only app. That and my shiney new iPhone 3GS is just craving for me to build some apps for it. So here we go. You'll need a Blinksale account to try it out - but that is the entire point after all.
Please let me know if you have any comments or suggestions.
I actually forgot the URL, but here you go:
https://go.invoicie.com/
For the security conscious: Invoicie doesn't store anyone's password. They are only used to access the API for your current session and are actually sent (securely over SSL) with every request. When you aren't using Invoicie it has no idea what your password or account is.
flankk: I never said I'm against testing, I just don't do it and these are some of my reasons. I'm mostly against those who think if you don't test, you are automatically stupid. I'm not writing a banking application, I can afford to fail sometimes. Usually your code fails in places you wouldn't think about, testing will not prevent that.
flankk: I can't stay agile when I'm rewriting 500 tests that failed because I changed the implementation of a method.
I think I'm going to start posting these short posts (mattly style) when I see something ridiculous or interesting on #ror.
Looks like a potential new RailsBizConf in the works says Obie Fernandez in a message to the rails-business google group:
I am in preliminary stages of planning a business-oriented conference
for principals of agile/rails consultancies. We will cover everything
from sales and marketing, to financing, to keeping your clients happy
and surviving in these tough economic times. [emphasis mine]
If you'd like to weigh in on RailsBizConf 2009 please do fill out the survey. The first question caught my eye:
My recommendation to Rails shops trying to trim some fat from the books: Fewer discretionary trips to exotic tropical island paradises.
Or if you absolutely must... vote Bahamas and fly coach. :-)
I think OS X will ultimately figure out (give it a few minutes) that you've changed the menu but if not you can run the following command from terminal to clear the cache:
`locate lsregister` -kill -r -domain local -domain system -domain user
Open-With Manager seems to have decent defaults for pictures and movies for if your cup of tea is something else entirely the preferences allow a ton of flexibility.
The first case of the pot calling the kettle black this new year: Jason Freed blogs about Trademark hysteria and how trademarks are being misused by companies these days for the silliest reasons.
I wish he could apply the same critical thinking skills to 37signals own sad case of "Copyright hysteria" that I've quite vocally blogged about in the past.
Just because you can slap a "Copyright (c) 37signals, LLC" sticker on everything you touch (whether it's legally copyrightable or not) does not mean you should.
So I deploy an existing app using Passenger for the first time and hit this:
The only Google results had to do with components and how they could result in the sweeper's after filter getting called twice which would results in a nil controller variable the second time thru. But I wasn't using components.
Finally after adding a bit of logging to show me FULL stack traces each time cache_sweeper was called I found something interesting: application.rb was being loaded twice.
I use Exception Logger in this app so I have this small bit of code in my production environment:
That set's up authentication on the LoggedException controller so not just anyone can access it in production. The problem is line #2. We're requiring application.rb since we don't have it yet this early in the stack. But then Passenger is coming along a little later and requiring it again inside preload_application.
Thankfully Passenger is using require_dependency (which checks to see if the same dependency has already been loaded via require_dependency)... so if we used require_dependency also then we'd avoid this. A diff:
Problem solved. I'll be submitting a patch on github for this as well.
But is it really Passenger's fault?
Someone tried to make the argument that this has nothing to do with Passenger. I could argue it's not my require call that breaks anything but rather Passenger's later require_dependency call - but I won't do that.
My point of view is this: It worked before for years and when I moved to Passenger it broke. From where I'm standing it doesn't really matter who is to blame. Only that the app worked in a "traditional" Rails deployment (Mongrel) and did not work with Passenger.
Regardless of who's code is at fault I think this is the type of issue Passenger has to take some of the heat for. If someone comes out with a new car with the gas and brake pedals reversed I think one could make a strong argument that the car manufacturer shares some of the blame (if not most) for wrecks resulting from people hitting the wrong pedal. It's not a perfect analogy, but we don't live in a perfect world. :-)
This post is mostly intended to help others deal with similar problems they might have moving to Passenger - not just to cast stones at Passenger.
It seems the arts plugin has some problems with Rails 2.2.2. Seems to be a simple enough fix. I simply added the following to the bottom of my arts.rb file.
Embedded pastie:
It seems there was a new with_output_buffer method added in Rails 2.2.2. I'd guess it does something useful with regard to output buffering in the context of an actual request - but for testing purposes it seems to work fine if we add it to the Arts module and just have it call the block it's passed.
I used the examples/haproxy.spec to build a RPM of HAProxy 1.2. It was painless. 1.3 was a bit more annoying but I got it working and thought I should share the changes I made to the spec:
Embedded pastie:
This is the reason for Pastie's downtime earlier tonight *grrrr*. When I did get haproxy to build it silently died when run. Turns out /usr/share/haproxy was missing and it was silently trying to chroot there.
Note to developers: Such MAJOR errors should result in output without having to run your program in debug mode! Please!
Update: The author contacted me a few hours later with a patch for the silent error issue. Evidently for some historical reasons daemon mode triggers quiet mode which suppresses a lot of error messages.
So before I dug in to really work on Pastie I did a quick bump from 2.0 to 2.1. And I was instantly horrified at memory usage. "Memory out of bounds" e-mails were pouring into my inbox every hour two notifying me that Mongrels were getting killed and restarted by god. This was something entirely new.
Initially I thought perhaps Rails 2.1 was just more of a memory hog than 2.0. Perhaps I just needed to raise my memory ceiling and then things would be happy. Then I stumbled on to the real problem.
The Real Problem
Pastie makes extensive use of action caching to cache it's over 300,000 syntax highlighted Pasties. Rails 2.1 defaults to the memory store for caching rather than the file store (the previous default). And the file store for Pastie was easily over 10 gigabytes. Memory store, FAIL. :-)
Sometimes the problem isn't what we think. Sometimes it is. But sometimes the beginning of the solution should start with leaning back and asking yourself "What else could this be?"
It's been almost 2.5 years since Pastie #1. For the most part Pastie has changed little. I can only think of a few new features that have appeared since day one:
true integration with TextMate (ie, the ability to paste any type of file in full color regardless of whether Pastie knows how to syntax highlight it or not)
private pastes
the switch from CodeRay to Ultraviolet leading to the support of many more languages
This lack of updates is largely due to my feeling that Pastie does everything it was designed to do - and does it amazingly well. I will concede though that Pastie has been a bit neglected recently. Other things have had my attention and Pastie has taken a back seat and also gotten a bit of a reputation (in some circles) for being finicky when it comes to reliability.
Recently my focus has returned to my beloved Pastie. Code has been re-factored, new features have been added while performance, responsiveness, and reliability have been restored.
Along the way I've learned a few interesting things that I'd like to share. I don't know if any of this will be astounding or rocket science. But maybe you'll learn something new or just find a new way to approach a problem you're having with your own app.
So you like pasting your code to Pastie, but you've always wished it was easier to include that same code in your blog or webpages? Wish no longer.
Below is an embedded Pastie of a cute little helper I wrote during the process of adding this feature.
Here is an example of how Pastie use's the helper to avoid worrying about all the document.write stuff... and just concentrating on building a straight HTML view.
I'm also thinking of allowing you to pass a param that determines which of the available color themes your Pastie is displayed with.
Any thoughts of ideas? Does this fit the bill for those of you who've been wanting an easier way to get Pastie's into your blogs?
Ok I spent WAY too much time getting this to work so I'm just going to tell you what finally worked for me.
* Edit your ports down to 5.8 and port install oniguruma5 (5.9.1 might work, haven't retried it)
* ln -sf /opt/local/include/oniguruma.h /usr/include
* ln -sf /opt/local/lib/libonig.2.0.0.dylib /usr/lib
* ln -sf /opt/local/lib/libonig.2.dylib /usr/lib
* ln -sf /opt/local/lib/libonig.dylib /usr/lib
* gem install oniguruma
Essentially we're just tricking it into thinking the bits it needs are installed in the more traditional locations.
On my other computer I'm using ruby from ports... and this was 100% seamless... and there may be some way to pass the right args to gem install to get it to find the include and link things properly, but if it can be done I couldn't figure it out.
