Tokaido is not dead. It's taken longer than I expected, but I've been wrapping up the requirements for the MVP over the past few weeks [1][2][3] and hope to integrate the code I've been writing into the UI in the next few days.
I initially anticipated that I'd be able to spend a number of full-time months on the work. I ended up being able to allocate time on a less consistent basis, largely because starting a company (tilde.io) ended up offering fewer opportunities for dedicated, isolated work than I expected. Thankfully, Patrick Gibson (of Tilde) and Austin Bales (of Do.com) ended up doing some of the iOS and design work, respectively, and I've focused my energies on the Ruby parts of the architecture.
My talk at RubyConf[4] goes into some detail about the architecture, and we're very close to shipping an early beta.
During the (long) time it's taken me to get this out the door, I've worked closely with Michal Papis (of rvm) to make the static binary build viable on both OSX and other Nix environments. Michal briefly shipped the binary Tokaido build as the primary build for `rvm install 1.9.3`, but difficulties in reliably building more recent patch levels have pushed that back some. We expect to be able to use the Tokaido build process to permanently ship binary rubies with rvm (and other ruby managers that are interested) once the build process for the current patch levels stabilizes again.
My plan for the MVP release of Tokaido is:
* Shipping the binary with a .app that can be dragged into /Applications
* The ability to add and remove applications via an application UI. You can then open a terminal window for these applications with a rock-solid Ruby environment that uses the binary build and makes sure that the ENV is set up correctly.
* The ability to start and stop any of these applications (via the web section of a Procfile) and browse them via `appname.tokaido` in the browser. This involves installing and executing a pure-Ruby proxy that supports the `app.tokaido` domain (see my RubyConf for more details on the nature of this beast; SMJobSubmit ftw!).
All of the above is largely complete (see the `tokaido` organization on GitHub and the links above for more). We have worked out how to use `SMJobSubmit` to enable the parts of `appname.tokaido` that require superuser access on first boot of the application bundle, and Patrick is just waiting for me to give him a fully self-contained zip of `tokaido-bootstrap` to execute from within the application. Of course, error handling is crucial for this, especially for low-level things like DNS servers and HTTP proxies.
Post-MVP, we hope to work on some of the more ambitious logging aspects of Austin Bales' original design.
Based on the comments, it looks like people are still waiting on handwritten thank-you notes and stickers which the Kickstarter project says were to be delivered in June/July 2012.
> I ended up being able to allocate time on a less consistent
> basis, largely because starting a company (tilde.io) ended up
> offering fewer opportunities for dedicated, isolated work than
> I expected.
The stated goal for raising $25K (and any excess) was to take time off of work to dedicate 100% to this, at least until Rails.app shipped. What happened?
> Based on the comments, it looks like people are still waiting on handwritten thank-you notes and stickers which the Kickstarter project says were to be delivered in June/July 2012.
I have been furiously writing them over the past few weeks (at a pace of about 30 per day). I have about 500 to do in total and I've done about 300 so far. My intent was to deliver them around the same time as the beta release, so that the thanks would be meaningful.
> The stated goal for raising $25K (and any excess) was to take time off of work to dedicate 100% to this, at least until Rails.app shipped. What happened?
You're absolutely right. The original plan was to be able to take a few months off of work and use it to replace any lost company revenue. In other words, I was going to pay for my own time to replace consulting revenue. Co-founding a company turned out to be more time-consuming than I expected (I know that sounds stupid, but it's the first time I did it), so I wasn't able to purchase my own time in a single block. Instead, I used whatever available time I could manage and used the money to fund smaller blocks of time.
I also used some of it to fund full-time work by Patrick Gibson, an amazing iOS/Cocoa developer (he worked on the original iPad build process for Apple and the Batch app) who works for Tilde, so I could focus my energies on the necessary Ruby code.
I'm really sorry that my original estimates didn't work out. That was absolutely a mistake on my part and I have learned a lot from the mistake (and my inability to follow my original plan precisely has caused me a great deal of heartburn). In the long run, I will not allow this error to prevent Tokaido from shipping. See my other comments on this thread for more details.
I think some folks might take issue with the idea that you were starting a company while this project was in progress. (I didn't contribute, and I understand multi-tasking, but my impression was raised funds were to capture your undivided attention; unsure if others had same interpretation)
I had publicly started Tilde about six months before starting the Kickstarter.
I said that I would use the money to take time off from work to dedicate to Tokaido. I naïvely assumed I would be able to take that time off in a large block, but that wasn't possible. Instead, I took off time as I had it available, in spurts rather than all at once. I isolated the money so that I would mark portions as "earned" only as I (or Patrick, who did much of the OSX work) actually worked on the project, so I did use the money to dedicate time to work on the project.
I am extremely sorry that my original plans for dedicating a block of time turned out to be infeasible. It was my mistake and one that I have learned from the hard way.
It's great that you've isolated those funds, and are accounting properly. I think a number of "failed" crowd-funded projects fail in this regard.
I know on the project you referenced using Harvest to track time - perhaps you could use Harvest's API to publicly disclose how much of the funding has been "burned down"? (I think this would be a good idea for all Kickstarter projects)
Yehuda, I want to say thank you for your efforts on this. I understand that the plan changed, no problem. When I look at all the volunteering you do (W3C’s TAG?) I can't believe there is only one copy of you.
This guy has worked on all sorts of awesome shit that he gives completely free to the community. Heaven forbid he miscalculate time like 90% of Kickstarter. Yehuda clearly didn't take the money and spend it on beer and hookers so let's collectively get off his ass about sending a few postcards out late.
Every Kickstarter project gets delayed, and as Kickstarter keeps hush about, funding a project gives you exactly zero guarantees of anything. If you expected anything less, well, I can't entirely blame you, but you should have known better.
Funding a Kickstarter project creates a legal obligation on behalf of the project creator to provide the reward for the donated amount [0], even if the project itself is ultimately unsuccessful.
Of course, should a project go so off-track that a backer is compelled to seek a refund their claim is against the creator, as Kickstarter disclaims any responsibility.
I was addressing calinet6's comment that one should expect nothing from a Kickstarter project. Sorry if my comment came across as implying you weren't fulfilling the rewards; it was meant in the generic sense. It's awesome that you're on top of things.
I don't really care when tokaido ships. I've been very grateful to being able to piggyback on your work for years now. A few bucks to back whatever you want is the least I can do.
Thank you for the update. I'm glad the project is still progressing. Also, thanks for mentioning Michal Papis. I know he's been working hard on binary builds of Ruby for both RVM and Tokaido.
I'm using my first post to thank you for what you already have done and look forward to this when it is ready. In my experience, biting off more than it turns out you can chew is a trait common to prodigious coders such as yourself. There is no better evidence than the (audacious!) projects you have tackled and completed in the past - leaving me confidant you will deliver Tokaido and it will be awesome. (but curious about all the hand-wringing by those surely not aware of your accomplishments) Code you have released freely in the past helps puts food on the table of lesser developers such as myself and I just wanted you to know you are appreciated.
>I initially anticipated that I'd be able to spend a number of full-time months on the work. I ended up being able to allocate time on a less consistent basis
So you pocketed money from Kickstarter contributors to do something, and then you put the project in the back burner and gave priority to something else.
And not for serious health or personal reasons (which would be totally understandable). Just to start another business.
Nice.
Will keep it in mind the next time somebody asks me to fund a Kickstarter project.
JewelryBox is vastly underrated and undermentioned, as far as I can tell. It takes away pretty much all of the work involved with dealing with RVM and has been nothing but a great help since I first installed it a couple months ago.
Most of the interesting parts of Tokaido are in tokaido-bootstrap, muxr, tokaido-dns, and tokaido-build. They will be integrated into Tokaido.app in the next few days.
While I'm interested in this (on a similar note, heroku's postgres app has been great for me), it seems like having to install and manage Rails is an important thing for new people to learn.
This is especially true if one wishes to push code to production and so on--even with when using Heroku, one still needs to understand the command line side of all of this.
It seems like having to install multiple different versions of Ruby/Rails is an important thing for a new person to learn, but we have RVM.
It seems like getting a rails app deployed on a server is an important thing for a new person to learn, yet we have Heroku which takes little effort.
We can say this about many of the things ruby/rails and the community has abstracted away for us, but that doesn't mean these tools aren't important in moving forward as a community.
I'm no slouch as a developer. Yet when I've installed RVM on 5+ systems, something _always_ goes wrong, and never in the same way. When it works it works great, but when it doesn't you spend your day bashing your head into a wall.
How will we encourage new programmers to join Rails and the Ruby community when they fail to even get it running?
I get what you're saying, but the thing is that it's really not difficult to get running. Especially on a Mac. Especially now that we have bundler and such. The only thing one really has to manage is ruby versions, and that can be done with rbenv/rvm.
But doing everything in an app really does have the possibility of hurting one's ability to put code into production, even with heroku.
> I get what you're saying, but the thing is that it's really not difficult to get running. Especially on a Mac. Especially now that we have bundler and such. The only thing one really has to manage is ruby versions, and that can be done with rbenv/rvm.
I'm not interested in Rails.app, but I must correct you on that: it isn't difficult to get a Ruby environment running in most cases.
When you've spent half a day puzzling over why your colleague's new Macbook Air won't build Ruby despite everything seeming to be in order you'll never be so sure of how long setting it up will take.
Yeah, I was wondering the same thing. Rails, on a relatively clean system, is so easy to install through the command line that if you can't do that work...then you may not be the kind of person who can easily debug a basic Rails app in the first place...Not trying to be elitist here, as I'm the kind of person who runs homebrew scripts without reading the actual scripts. Just saying that if you can't even do that, then all the post-installation work of Rails is going to be a painful slog.
A significant portion of the Rails ecosystem -- who we should encourage -- is people coming into web development from a background which doesn't include an engineering degree or years of command line experience. For example, many of them are designers or folks who've otherwise built web pages, for whom <h1><%= @post.header %></h1> is an awesome step forward in terms of their ability to deliver software which solves actual problems.
Eventually, a few years from now, they'll have a better understanding of the full stack, but for now, we want to clear as many possible roadblocks from their way so that they don't either abandon web development or begin using Programming languages which are reasonably Hospitable to People who come from non-traditional backgrounds.
Technologies require mindshare - Tokaido is software conversion optimisation for Rails.
Also "relatively clean system" is an important qualifier. A lot of curious developers won't have one of those, and instead will have to deal with dependency hell and tedious gotchas.
Jumping into learning about the framework is better use of their time upfront.
Having spent a morning this week showing journalism students at Mizzou how to install Django, I would very much like the ability to say "oh you want to try rails? Just download Postgres.app and Tokaido.app and you're set."
Also, this is a weird conversation to be having with a dude who has a book for teaching beginners Ruby (http://ruby.bastardsbook.com/ )!
Ha! I'm all about teaching beginners how to use Ruby, which is painful in itself. By the time they get to Rails, they had better be used to typing in commands at a text prompt :)
No seriously, though...So many things can easily go wrong with basic Rails...not because Rails is bad, but because Rails has so many features...that if people haven't mastered the art of Googling lines from debug-output or command-line install instructions...then the time they've "saved" by having a push-button solution will be more than spent in the time trying to get off the ground.
But I'm obviously speaking from hindsight...as I've gotten more experienced, I've seen that writing script for minimal apps is more efficient than launching a full-fledged Rails app. However, I may have lost interest in the whole web-app game long ago if I didn't have the chance to play around (clumsily) with Rails 2.2
http://www.youtube.com/watch?v=4iv3Gk95-v0
https://twitter.com/wycats/statuses/293594028518277120