March 30, 4:22 | Comments (34)
Paul Graham is writing about the Mac adoption amongst hackers in general and his own return in particular:
All the best hackers I know are gradually switching to Macs... The reason, of course, is OS X. Powerbooks are beautifully designed and run FreeBSD. What more do you need to know? I got a Powerbook at the end of last year. When my IBM Thinkpad's hard disk died soon after, it became my only laptop.
It's great to see that over the past few years it has become the norm, not the exception, that good programmers are wielding Macs. There's the odd exception of Linux here and there, but the writing's on the wall: OS X offers the best personal computing experience available today.
While I can certainly understand the reasons why some people go with Linux, I have run all but dry of understanding for programmers that willfully pick Windows as their platform of choice. I know a few that are still stuck in the rut for various reasons — none of them desire.
I would have a hard time imagining hiring a programmer who was still on Windows for 37signals. If you don't care enough about your tools to get the best, your burden of proof just got a lot heavier.
So if you haven't switched already, stop procrastinating. Get it over with. If you have any desire working for the rising rank of companies building their business on open source technologies, you don't want to carry a liability like that around on you resume. Being labeled a 2005 Switcher is bad enough.
UPDATE: Of course the discussion continued off-site, so I elaborated on my position in two takes on the Ruby mailing list.
March 29, 12:51 | Comments (21)
Ian Bicking has issued a call to arms for the Python community under the banner of Why Web Programming Matters Most. In the piece, he expresses his frustration with web programming not being more in the center for Python and longs for the growth curve of PHP.
A fellow Python programmer, Jonathan LaCour, responded with his opinion that Rails should be the model for how to turn Python into a relevant force in web programming and prevent that "...Rails will be the dominate open source, dynamic web framework for the next few years at least":
I don't even like Ruby very much, but Rails is obviously the best web framework out there because of the tightly integrated simplicity of it! Rails is the Apple of web frameworks — one tightly controlled stack. Sure, you may lose some flexibility, but you gain beauty, simplicity, and ease of use! I really really wanted to pick Python, but I just couldn't do it. There are too many frameworks, none of which are as good as Rails.
Jonathan further argues the damage of excessive choice and the prevalence of Not Invented Here syndrome in the Python web world. As a tangent to this discussion, I highly recommend listening to Barry Schwartz's excellent talk on The Paradox of Choice: Why More Is Less from Pop!Tech 2004.
In short, indistinguishable choices (or just too many) leads to lower satisfaction with the eventual pick and increases the chances that no pick will be made at all. The latter seeming to be exactly what Jonathan describes by being overwhelmed with choice of Python web frameworks and then picking an entirely different language altogether.
Unfortunately, it seems that there is little faith in resolving the situation of choice overload. Glyph Lefkowitz describes it as:
I can understand being frustrated with the proliferation of web frameworks, but let's face it: there is no way you are going to be able to convince anyone to give up on their pet framework to work on someone else's.
I see a lot of people in the Python web community complaining about proliferation of frameworks. I don't see anyone at all standing up and saying "My web framework X is unnecessary, I will abandon it and spend my web-framework development time working on web framework Y instead."
So there's a a somewhat shared understanding of what the problem is (too many, too similar frameworks of varying quality), a somewhat shared sense of a possible solution (combine efforts to get fewer, but stronger choices), but no will for the sacrifice or cooperation needed to make it happen.
Jonathan compares this situation of unsatisfactory choice with what we're doing in Ruby:
In the Ruby world, if you are developing a web application, there is no choice: there is Rails. And thats okay, since its so damn well done. In the Python world, if a web framework doesn't do something that you want, you just create your own framework... why not fix the original one? The whole situation is embarrassing.
Of course this is an oversimplification. There are quite a few other Ruby solutions for how to deal with the web problem. And new ones still appear, like the recent introduction of Wee (a Seaside-inspired framework in Ruby).
That being said, I strongly believe that there's a big benefit in having a dominant framework draw a strong profile for a small language. The amount of positive attention Rails has been able to shine on Ruby for a long time has made me particularly proud. Languages need blockbuster hits like that to establish their authority in the public perception for a given domain.
I'll continue to do my earnest in order for Rails to stay deserving of this honorable role for Ruby. The growing community around Rails is intent on doing the same. We're just pushing ~30,000 downloads now (through gems, across all versions) and are aiming to get that into the hundreds by year end.
I wish the Pythonists all the luck in finding their own formula for raising the attention of Python as a web language. Just as I welcome Pythonists that would like to give Rails a try while waiting for the former to happen.
March 28, 0:40 | Comments (1)
I heard Rickard Öberg talk about his aspect-oriented framework at JAOO 2004 and was thoroughly impressed. Unlike all the run-of-the-mill logging and security examples that has been traditionally been used to describe the benefits of aspects, Rickard showed just how deep the rabbit hole could go when you let aspects drive the core of your domain.
Now he's sharing the story of his company Senselogic and how they managed to flourish as a small team betting on new technology as an competitive advantage in the otherwise "boring" market of content management. Needless to say, my mind is drawing parallels. His reasoning for turning down VC strings rings very familiar too:
Not having that "luxury", or false sense of security, meant that we had to be really focused on what we wanted to do, get customers fast, and make sure that whatever code we wrote initially was more than just a fancy prototype, something we could continue to work on once the first release was done.
Rickard goes on to touch on many of our dear values at 37signals:
- Cross-disciplinary developers: "As many new startups everyone in the company have had to peform several roles. Developer, support, training, installation, sales..."
- Preempt support with good design: "...if you create a new feature and it is not what is typically needed, or it is very difficult to understand how to use it, it means that a) you're getting more support calls b) training is more complicated and c) the customer is less likely to describe your product in stellar terms to other potential customers".
- The product is the best promotional tool: "People are sick and tired of promises and hypes. They want to know what the secretary who has to update a webpage has to put up with. So that's what we show 'em."
Thanks for sharing, Rickard. Hopefully you'll get the time to share your aspect framework with the world at some point. Although in Java, I'm sure there's a lot of lessons I would love to learn from it.
March 23, 17:15 | Comments (10)
Dave Thomas has revealed the not-so-big secret that I've jumped on board Agile Web Development with Rails as a co-author. Dave is definitely the driver of this title, but I'll be writing about "Deploying and Scaling" as well as doing a series of "David says" sidebars explaining the philosophy of Rails.
Just as importantly, I'll be making sure that the book represents the state of the art in use and approach of Rails. As Dave says:
So how do you go about writing a book about a technology that’s advancing every week? How do you make sure that you capture both the detail and, as importantly, the spirit behind the surface? How do you make it the best book it can be?
Seems to me that a good way would be to have the guy who invented the technology help write the book.
I'm honored to be on board. Seeing my name on the cover of a book is one of my 17 things after all. And to see it happen along side one of my all-time favorite authors is, literally, a dream come true.
It's amazing to see all this book action. Agile Web Development with Rails will definitely be the foundation, though. The bible title you get first and then compliment with all the others coming out. I'll try my very best to make it deserving of this pole position.
March 23, 0:27 | Comments (9)
It's time to drop the code name. Honey is Backpack. The next big thing we've been working on at 37signals. It's an application we've been trying to narrow down in our heads for the better part of six months, but only recently acquired a focus sharp enough to start Getting Real.
And getting real we have. Backpack has once again provided me a fresh slate to experience the Rails anew, which always gives rise to a wealth of new ideas. I couldn't build a better framework any other way even if I wanted to. Frameworks Are Extractions and all that.
We've already extracted a big chunk of the technology already, actually. Remember those shiny new Ajax helpers in Rails 0.11.0? That's a Backpack extraction. Since the scope of this application is significantly larger than that of Ta-da, there was simply no way I was turned every Ajax opportunity into a mini-project of its own.
Those constraints again. If we had allowed ourselves to allocate an abundance of resources, we would perhaps just had followed what we knew from Ta-da. Did the mini-projects. Poured sweat and tears into hard work of hand-held Javascript. But we couldn't, so we didn't, and there you have it: A need to innovate.
Actually, that script/runner we also added this release. Backpack extraction. Oh, the incoming email support for Action Mailer? Backpack extraction.
No wonder the lines of code is currently a mere 585 despite having an application that does a ton more than Ta-da. I'm extracting every infrastructure breath I take. Luckily, I haven't drawn a kitchen sink yet.
But what do you care about technology. Do you want to know what it is, Neo? Yeah, I'd love to tell you, but what fun would that be. We're still 30-45 days from a release so why don't we leave it at what the trailer says:
Backpack helps you bring life's loose ends together
It's true too. My loose ends are being tied together awfully well. We've been eating the dog food since the application was a mere 100 lines.
Intrigued? How about signing up for our announcement list. We'll be picking beta testers off that list too.
Backpack is coming soon — it'll be better, not beta.
March 22, 15:48 | Comments (27)
Rails 0.11.0 is out on the street and I'm especially proud of the Ajax support we've been able to include. Instead of trying to soften the blow of doing client-side Javascript libraries as many others are doing, we've gone ahead and more or less removed the need for hand-written client-side javascript entirely.
This is done by off-loading the creation of DOM elements to the server side, which returns complete constructs that are then injected live through innerHTML. While this method is slightly more verbose than just peddling data across the wire, it's immensely easier to develop.
And especially the ease of development is critical to the success of Ajax. I used the old style of hand-crafting the DOM on the client-side with Ta-da List and was quite disillusioned at the mess of browser differences and the sheer effort it took. Basically, each sliver of Ajax was a project in itself.
With Backpack, though, I've been all over the new Ajax style that Rails affords. And what a difference it makes! It's basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.
We can argue about the name, we can argue old wine on new bottles, but the attention this technique is getting and its integration in frameworks like Rails will rocket its use to the moon and further blur the decision on when you need to go rich and when not to.
March 22, 11:49 | Comments (1)
O'Reilly is getting on board the Rails too. Their first book is going to be the Rails Developer Notebook, which as the name suggests is part of their Developer's Notebooks series:
The Developer's Notebook series is for early adopters of leading-edge technologies who want to get up to speed quickly on what they can do now with emerging technologies. If you're a coder down to your core, and just want to get on with the job, then you want a Developer's Notebook. Coffee stains and all, these books are from the minds of developers to yours, barely cleaned up enough for print.
The book is being coauthored by Bruce Tate (Bitter Java, Bitter EJB, more) and David Geary (Core JavaServer Faces, Core JSTL, more). The writing is supposed to start in April and the book should be out by June. So the focus is definitely to get something short out early and quickly.
If you've been following Rails advocacy, you may remember the name David Geary. I ripped into him fiercely about a month ago as he quickly dismissed Rails as being nothing but a CRUD scaffolder and declared "...you take this ROR koolaid. I'll stick with the JSF flavor".
Luckily, it didn't take much more than two weeks for Geary to reconsider the dismissal and commit to looking closer at Rails. And now just a month later, he has signed on with Bruce Tate and O'Reilly to write a book about Rails!
What a fantastic and inspiring transformation. Hopefully Geary can serve as a role model for other Java developers who are feeling "...a bit nervous about this ROR thing". Despite being heavily vested with Struts, Tiles, JSF, and Shale, he was able to see that there was amble room for a competing stack and jumped on to it.
My warmest welcomes to the Rails world, Geary! I wish Bruce Tate and you the best of luck with the Rails Developer Notebook and can't wait to read it.
March 21, 14:07 | Comments (2)
I'm incredibly proud to announce the third Rails book in the making. The title is "Pragmatic Rails Recipes: A Guide to Elegant Web Development" and the authors should be very familiar to the Rails community: Marcel Molina (noradio) and Scott Barron (htonl). They've been around since the first release and are both integral parts of the Rails community through their programs, writing, and help on IRC.
The publisher is Dave Thomas' progressive Pragmatic Bookshelf. The same umbrella that'll carry the first Rails book to be published, Agile Web Development with Rails. This will of course ensure that the two books will become very complimentary and that they'll both be available in my favorite reference book format: PDF.
It's still very early in the process, the signatures on the contract is hardly dry, so the release target is tentative at best. Never the less, Scott and Marcel are aiming at October of this year. That'll give the three books current announced a nice spread. Dave's book around July, this one around October, and the German book around December/January.
That's of course not to say that we can't fit more books into the calendar. Quite the contrary. And from the handful of offers I've been getting from various authors and publishers, I'd be quite surprised if we didn't see at least a couple of more Rails book announced this year.
Exciting times indeed.
Scott also talks about the book today.
March 18, 11:57 | Comments (15)
Yahoo! Research Labs has a pretty cool new app out making markets out of buzz called Buzz Game. It uses the Yahoo search engine to identify hot topics and assigns a dollar value based on that. When you sign up, you get $10,000 to trade for an can invest as you see please.
Now the reason this is terribly interesting is of course that they have a Web Application Frameworks market. And as I spotted this, I saw that Rails was already trading at twice the value of number two (Flex) and more than four times the value of Java. Wow!
Puzzled as to what all this would mean, I asked recognized internet entrepreneur Thomas Madsen-Mygdal. As the founder of internet conference Reboot, co-founder of wifi hotshot Organic, and a slew of other companies, I knew he would know. While Rails was trading at $22, he predicted:
I see the core fundamentals in the Rails market taking it to 80 dollars six months. A strong buy recommendation.
Holy moly! That's a four-fold increase prediction right there. Not one to distrust Thomas, I immediately invested all my starting capital of $10,000. Are you in yet?
March 17, 14:24 | Comments (18)
Software patents are horrible inhibitors of innovation and destructors of the competitive landscape. We need to make this statement early and often every time evil doers like Microsoft attempts to lock down an area of interest in IT or computer science. And this is exactly what they're trying to do with US patent application #20040210818:
Word-processing document stored in a single XML file that may be manipulated by applications that understand XML
A word processor including a native XML file format is provided. The well formed XML file fully represents the word-processor document, and fully supports 100% of word-processor's rich formatting. There are no feature losses when saving the word-processor documents as XML. A published XSD file defines all the rules behind the word-processor's XML file format. Hints may be provided within the XML associated files providing applications that understand XML a shortcut to understanding some of the features provided by the word-processor. The word-processing document is stored in a single XML file. Additionally, manipulation of word-processing documents may be done on computing devices that do not include the word-processor itself.
Are you kidding me?! For every step in the right direction of openness and transparency that Scoble is able to take Microsoft, the true nature of the beast unveils itself and goes 10 steps backwards.
March 13, 16:07 | Comments (9)
Jason took down SXSW yesterday with How to make big things happen with small teams — an hour's worth of insight extracted from the Building of Basecamp workshop. And boy, did that have an interest at SXSW. Around 180 people were trying to fit in the obviously way to small room:
Terry Storch was in the room and writes:
Jason was by far the best speaker that I heard today. Jason is a very charismatic communicator that also knows what he is talking about. Jason is the president of 37 signals, a web design and software development company. 37 signals would best be know for Basecamp, a web-based project management tool.
What a shame that we've pretty much already sold out the upcoming Building of Basecamp in Chicago. I bet Jason could have sold out another workshop by the engrossed audience.
March 11, 20:10 | Comments (9)
So I ripped into David Geary pretty good a while back for his early look at Rails, which I found to be... uhm... "lacking". But there are no grudges, only additional information.
Geary is pent on acquiring that and I'll cheer him on for that! Change can be an unsettling place, but as long as you recognize your own emotions, you're going to be fine. Geary writes about that with:
To be honest, I'm a bit nervous about this ROR thing. I've poured an awful lot of David Geary into Struts, Tiles, JSF, and now Shale and it'd be really hard for me to admit that something else is better than that stack. On the flip side, Ruby seems a lot like my beloved SmallTalk and ROR is a youngster, so hopefully I can climb up the learning curve quickly.
Excellent, Geary. Glad to have you take another look. There's nothing like peer pressure from people like Bruce Tate and Dave Thomas to offer an opportunity for revisits.
March 11, 17:42 | Comments (10)
Dion discovers the pleasure of removing code. This is also by far the most enjoyable aspect of programming for me. When I'm able to remove code, it means that my understanding of the domain has deepened. Some times it's just picking up another Ruby insight that turns three template lines into one succinct expression. That's satisfying in the "getting closer to my tool" kind of way.
But more interesting is it when the domain model reveals itself. When once fuzzy associations and unsure delegations become crystalized abstractions. I've had this experience a good handful of times with both Rails and Basecamp. When it clicks and you spot the missing class or the deeper pattern, there's a unique burst of energy released. The light bulb that goes off.
And this is where I think test-driven development has been most rewarding. It gives you the courage to execute on the deeper understanding. To radically simplify through swift cuts and add missing bridges.
The few times where I haven't had the comforting confidence of a good test suite when discovering an insight have been some of the most frustration ever. The gold is right there, yours for the taking, but you dare not grasp for it in fear of what hidden traps you'll uncover. It's horrible.
Especially because the mind is now set on the gold. The regular joy of working with the rest of the code base drops below zero when you know that an executable insight is available.
So, like, do your tests, 'mkay?
March 11, 2:11 | Comments (20)
My partner in excellence, Jason Fried, has been interviewed by O'Reilly's Marc Hedlund under the title The Builders of Basecamp. It shall be no secret that I was a huge fan of 37signals and Jason's work and ton long before I actually got involved with the company some three years ago. This interview does a fine job of highlighting a lot of the reasons why.
Jason has an incredible passion and drive for keeping it simple, telling it straight, and delivering. I'm frequently counting my lucky stars that he decided to attempt to learn PHP back in '01, that he couldn't make it work and asked for help, and that my help got the relationship going.
Asked about why we went with Ruby and subsequently extracted Rails, Jason speaks straight to my ideal on management and cooperation:
If you don't trust your developer to choose the right environment, then how can you trust him to build the best application? Trust is critical here. And, further, why would you dare impact your developer's morale by throwing him or her into a language where he can't be as productive or as satisfied? You only get good work from people who enjoy doing the work. I'll take a happy average programmer over a disgruntled, frustrated master programmer any day.
From that, it's not hard to see how we were drawn to the vision for Basecamp:
Our baseline approach is this: project management is communication. Projects don't fail from a lack of charts, graphs, tables, reports, stats, spreadsheets, and so on. Projects fail from a lack of simple two-way communication.
I wouldn't want to run a business with any other partner in the world. I wouldn't want to run any other business than 37signals in the world. And I wouldn't want to work on any other products than the family we're building with Basecamp, Ta-da List, Writeboard, and Honey. I'm having the time of my life in the best possible company.
So that's my round merry, happy back padding for today :)
March 10, 13:56 | Comments (23)
Bill Katz is a fiction author and technologist currently busy on his new venture Writertopia. He's also very interested in the beauty of Ruby on Rails and how it relates to Paul Graham's love for LISP:
Graham talks about bottom-up design, changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.
"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.
This is with out a doubt one of the Ruby features that excites me the most. The ability to evolve your own dialect of the language to fit the domain. The purity and beauty in code like the following is intensely satisfying (this is not pseudo code, it's fully executable without a precompiling code generation phase):
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_and_belongs_to_many :categories
validates_presence_of :name, :description
validates_acceptance_of :non_disclosure_agreement
validates_uniqueness_of :key
end
Which is also why calling glue kits like Trails a clone of Rails in Java just makes no sense (and exposes the sender of such a statement as uninformed at best). Replicating a single feature of Rails, such as Trails does with Scaffolding, does not a clone make. Not only is it a pick on one of the most shallow features of Rails, but it also possesses none of the elegance. Katz addresses this with:
When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process.
When Bill Katz calls Rails "...a work of art in progress", I can definitely imagine Serious Developers tuning out: "Code is not supposed to be artistic, just functional". To me that's a terribly depressing statement. Code that can be both "art" (as defined by striving for elegance and readability as primary motivation factors) and functional is what makes programming interesting to me.
Oliver Steele from Lazlo touched on many of the same issues.
March 09, 13:27 | Comments (21)
While there wasn't much hesitation before sharing our troubles with the latest upgrade, I did pause for just a second. Will people think less of us because we didn't do this or that? How will the story reflect in the light of calm analysis and perfect hindsight? Luke offered just that view in the comments:
...building solid web applications is your THING. And that's not just about development. You need to take some of your developer brilliance & insight, and invest I tiny bit into the operations side of what you do too.
Which is a fair stance. But it's of course also what makes a lot of companies terrified of sharing stories of trouble. And what gave me pause. In the end, though, I believe that the net benefit of transparency far outshines the small bruises you'll inevitably in return.
As an example, we're currently conducting an open-ended questionnaire with our customers asking what they like, don't like, and would love see changed. I took especial comfort in this comment on what to like about Basecamp:
The clean interface, ease of use, basic tasks are easy to execute. All features aside, I greatly appreciate the transparency of the operation. Not only has david released Rails to the world, but you guys (or David) had the balls to discuss the hardships felt during your recent upgrades. Most companies would leave it at "we apologize for the failures".. but letting/having a partner discuss the issues in detail is something you just don't get every day. It's extremely refreshing, and something more companies should emulate.
I believe this is part of the competitive advantage that small companies can enjoy if they dare. The freedom to say that you made mistakes. How you made them and why. The freedom as a partner of the company to say fuck, if that's how you feel.
P.S.: It definitely seems like the transparency is infectious. Jamis just shared another story on what can happen when you go to the keyboard ill. Hopefully we'll soon return to the stories about how we're conquering the world instead of how we're failing to ;)
March 08, 19:36 | Comments (14)
When we did the first Building of Basecamp, the last seats were sold just a few days before the workshop. The pace of registrations have steadily accelerated with each time we put on a new show. But this is getting pretty insane. We just opened for registrations five days ago and we've already sold more than half the seats!
Can't wait to get back to Chicago (the last two were in Seattle and San Francisco). I got my favorite flight (SAS SK0943, 9 hours direct) booked already. I hear they have wifi on the planes now, so that's going to be pretty cool.
Hopefully we'll be able to run a show just as good as the one Jason Hummel attended:
I attended a previous conference in Chicago, and I can tell you it's worth every penny. If for nothing else, just to see people speak who are passionate about what they do, and more importantly how they do it. Of course, if your like me, be prepared for lots of conflict at your job on your return, since you'll immediately recognize how wrong your coworkers/supervisors have it. You'll also wish a job opening would open up at 37signals. ;)
March 08, 19:15 | Comments (7)
The O'Reilly Open Source Convention is happening on August 1st until 5th and I just got the official confirmation that both of my proposals have been accepted. I'll be doing a tutorial and a session talk:
- Ruby on Rails: Enjoying the Ride of Programming: "Learn how to use the open-source web framework Rails to create real-world applications with joy and less code than most frameworks spend doing XML sit-ups. We'll get heads on and learn enough Ruby on the go to take us through to something useful. We'll examine all the major components of the framework and learn how they make up the full stack of Model, View, and Control." (3 hour tutorial)
- Extracting Rails from Basecamp: "Rails owe its origin to Basecamp and the experience formed the hypothesis that "good frameworks are extracted, not invented". The hows and whys of a successful web-application framework emerged from a equally successful real-world application." (45 minute talk)
I'm really honored to see both proposals being picked up. Especially considering O'Reilly had to reject three out of four proposals. I'm also really looking forward to be presenting back-to-back with Dave Thomas, who will be doing a 3-hour tutorial on Ruby.
With all the enthusiasm around Ruby (and Rails) at the moment, I don't have any doubts that we'll be presenting to packed rooms either. Especially since Rails 1.0 will have been released by then and we'll have at least one book about Rails out too.
UPDATE: _why is going to be at OSCON too! He's the village genius of weird goodness. Can't wait for his show. Oh yeah, the creator of it all, the honorable Matz will also be there. How can you not want to do everything possible to get to OSCON this year?
March 05, 15:12 | Comments (32)
Jamis Buck came on with 37signals as a full-time employee on Wednesday 3rd. On Thuesday the 4th at 7 AM (my time), we embarked on what would become a forty-four hour struggle to keep Basecamp alive during the worst server ills in the history of the application.
Continued...
March 04, 18:37 | Comments (5)
Building of Basecamp is happening for the fifth time on April 22nd where we'll return to Chicago for a full day's workshop. We'll be covering our approach to teams, vision, programming, designing, marketing — everything involved in launching a successful online venture, like Basecamp. This time we'll also be talking about Ta-da List and our upcoming application code-named "Honey".
All our previous plays have sold out in just a few weeks and received 4.5+ out 5 averages from the participants. So please, do join us in Chicago on the 22nd.
| 