saikat

Sean, you should jump into our campfire (https://stripe.com/campfire) or send us an email at support@stripe.com. We can try to offer a few suggestions for how to do this.

You would use Square for your in-person payments (Square, so far, is for brick-and-mortar stores whereas we are doing online payments). But we definitely are targeting developers more currently, so can see why we may not be as easy of a choice for you. We do offer quite a bit of analytics around what you are making and being paid out, and we also give you a viable way to get set up easily with minimal PCI compliance without having to use a hosted payment solution (so customers checking out wouldn't be sent to another website, which I believe PayPal's hosted solution does), so these features may appeal to you.

We work directly with Wells Fargo on our backend to make sure you end up with all the normal benefits of a merchant account (the money will be held in your name, you will be able to put whatever you want on your customers' credit card statements, etc.). We just want to abstract the whole process here -- basically, putting you on the account or accounts that makes the most amount of sense so you can start processing immediately and then continue processing at high volume.

We're working on international support right now -- though we don't have an ETA, launching in the US was definitely the first part of getting there (and we care a lot about going international -- about half our team is from other countries).

You don't need to make your own merchant account or payment gateway because we abstract over those details. We'll make whatever accounts are necessary and we work directly with the banks to make sure that your money is held in your name, what you want appears on your customers' credit card statements, etc.

Hey (Saikat from Stripe) -- not cheeky at all, but certainly flattering.

Sorry we've been kind of quiet (we do read Hacker News, though). We're just working hard to implement the feedback we've been getting from our existing users, and we want to make sure our product scales well and gets better as new people use it.

Here's a question: any chance you would be interested in having us watch you integrate Stripe? We've been doing this lately to try to make sure our first-run experience is really good. Send me an e-mail (saikat@stripe.com) either way.

This is pretty addictive. I've already bought 2 domains that I had been shirking on buying just because buying domains currently is kind of annoying. And once you buy the first one, it keeps your card on file, which makes it that much more tempting to buy every domain name ever.

Market opportunity for a new pub in Dublin.

You don't actually have to register a trademark to use the TM symbol. http://en.wikipedia.org/wiki/Trademark_symbol

I'm looking at http://demo.sproutcore.com/ (not sure about OP).

In Chrome 10, I can't get greenhouse to load any of the projects. In the family tree demo, clicking Add for Male, Female, or Pet doesn't seem to do anything. Trying to open outline hangs the demo page (and I can't then load anything else in the demos page without refreshing the page). Sorting by clicking on column headers in the table_view demo doesn't seem to work (maybe that's not meant to?).

Hope that helps!

Wall Street is large, and there are many types of firms there. Technology is a lot more important in a lot of Wall Street firms now than they used to, and, at the hedge fund I used to work at, programmers were the first class citizens and made many of the large decisions. The startup type is the perfect fit for these places - they want people who, with little management, can make innovative tools from scratch that will earn the place millions of dollars. And they pay a lot of money for this kind of person.

In the case that your app isn't CPU-bound, which is many cases.

[EDIT: Changed most to many. But I think arguments about whether or not speed matters are silly in the general case. Arguments about tradeoffs are always going to be so specific to your app that a general argument is fairly meaningless.]

Congrats on the launch. One bit of feedback - I might link the Coming Soon! text under "Enterprise" in the pricing page to some kind of e-mail collection form so you can let users know when it arrives.

Not sure if it counts since we have been in our beta for a while so it's not exactly an MVP, but we finally launched Mockingbird 1.0 in November (http://blog.gomockingbird.com/10-and-real-time-collaboration). I had been working on the real-time collaboration stuff for a while - felt good to finally get it out in front of users.

Are you guys using Socket.io under the hood?

Linode's SLA is monthly, so they are under for the month in Fremont. Though they will, of course, give credit.

That is an IRC channel. You shouldn't need your linode to use IRC?

Suggest also hanging out in #linode on irc.oftc.net. Perihelion is being very patient and answering questions.

This seems like a piece of advice that sacrifices truthfulness for wit.

The parent commenter's point is that this is a rule that matters.

Off-topic technical comment: the sign up page at grubwith.us gets a mixed content warning. It seems like you guys are hitting jquery from http://ajax.googleapis.com.

Hey -- sorry, but we aren't planning on open sourcing our OT framework yet. I would be more than happy to talk to you about about it though (my e-mail's in my HN profile).

You can actually resize the canvas. Just move the mouse to the edge and a resize tab appears. You can drag that to shrink it or input values into the text fields - https://gomockingbird.com/help/Editing/#resize_page. Hope that solves the issue at least part of the way (zoom would be nice though).

Sure. The majority of Mockingbird wasn't written using Atlas (we started on it a long time before Atlas existed), but we do use Atlas to make a lot of our panels (and if you use the --path flag with the flatten tool, you can load these panels up front to make the experience smoother). I've also heard good things about nib2cib in conjunction with interface builder if you're not liking Atlas.

I work entirely in emacs and use OJTest to test my code as I write it. Sheena (my co-founder) uses TextMate though, and I think that might be a better environment for someone starting out.

The best debugging trick I think I've learned is to use index-debug.html and enable objj_msgSend_decorate(objj_backtrace_decorator); (it's commented out by default). Other than that, I think I've learned to just try testing my code early and often with OJTest to catch things. I do want to try to build out better testing and debugging tools for Capp though.

In general, just ask questions on the mailing list and don't be afraid of coming into IRC. The #cappuccino IRC channel is one of the most helpful ones I've been.

Hey guys, Saikat from Mockingbird here - I'd be happy to answer any questions you might have about our operation transformation framework or about our launch.

There are actually multiple demos going on. If you go to https://gomockingbird.com/mockingbird/demo.html it will put you on one of the projects via ghetto load balancing (read: redirect to one of the demo projects at random).

The Operational Transform part of the wave code has been open sourced for a while as part of the open source wave-protocol. I have this link bookmarked though google code seems to be having some trouble loading it right now: http://code.google.com/p/wave-protocol/source/browse/#hg/src...

Also check out the wave whitepaper on OT at http://wave-protocol.googlecode.com/hg/whitepapers/operation.... The codecommit article is also really great (and probably the most helpful thing I found).

There are few ways in which this is not exciting. Hopefully this means even more momentum for an open source project that already has a ton of it.

I spent a lot of time looking at different frameworks, but in the end, it's pretty hard to judge them without diving in and actually making an app in it. So I have some knowledge of the Cappuccino competitors from my initial research, but obviously nothing as in-depth as my knowledge of Cappuccino, so take anything I say about the other frameworks bearing that in mind. Also this initial research was done around May of 2009.

The main selling points that drew me to Cappuccino at the time were 1) there was a live app using it (280Slides) that demonstrated doing a lot of the things I wanted to do with Mockingbird, 2) Even if there weren't tons of docs at the time, Cocoa documentation is very extensive and applicable, 3) Because it pretty much implements the Cocoa API, I knew I was getting an API that had been used successfully in tons of applications, 4) The promise of Atlas, 5) it made my app decent looking without my having to try very hard (though my co-founder Sheena did end up customizing the Mockingbird look and feel a lot), and most importantly (at least when picking a framework when you don't have time to get more than superficial knowledge of it) - 6) after spending some time in the IRC channel/asking a few questions on the mailing list, the creators and other members of the community were extremely helpful and welcoming, the 280North guys seemed to have a very good sense of where they wanted the framework to go and ideas for awesome features they wanted to implement, and because they were such good developers, I was pretty well convinced that they would actually ship their promises (and they have - Atlas, automatic mage spriting and app flattening options were all things that didn't really exist when I picked Cappuccino).

As for the other frameworks (and there were a ton, but I'll just talk about the ones you mention):

GWT - I didn't like the compile step, and I've done some Java and I don't prefer it. Also, bigger communities like GWT's have their pros and cons - you probably have more resources you can Google for, but it's not always as easy to just ping one of the core devs and get personalized help/get him to help you write your patch.

SproutCore - probably the closest competitor to Cappuccino back then. In this case, Atlas was a selling point for Cappuccino, and I thought Cappuccino apps looked nicer by default. I also don't remember seeing any impressive SproutCore apps in 2009 other than MobileMe, but I might be misremembering.

PastryKit didn't exist in the summer of 2009.

I believe Dashcode emerged as more of a web application creator with version 3.0, which was fairly recent. If not, I may have simply not looked much into it.

I don't remember looking at Coherence.

Heh - I should clarify. Gomockingbird.com definitely didn't get made in a week, but I did make a working prototype in a week.

At Apple, I did all OpenGL stuff (worked on Keynote), and Harvard was all C/C++.

Objective-C knowledge helps, but if you have little programming knowledge and need to learn either Javascript or Objective-C, I think Cappuccino makes it really easy for you to rapidly get a non-trivial web application working because they've just done a really good job of abstracting out a lot of the annoying-to-implement parts of a desktop-like application. I didn't know either Objective-C or Javascript when I started work on Mockingbird, and it took me about a week to learn enough to have a prototype running that had canvas (and VML) drawing, drag and drop links, and undo/redo support.