Pallet training scheduled for March 14-15 at the Clojure/West Conference

Registration is now open!

We are very excited to announce that Clojure/West will be hosting a 2-day Pallet training session on March 14-15 with both Hugo Duncan and Toni Batchelli as instructors. 

Clojure/West will be held in San Jose on March 16-17 and registration for the conference is also open. Make sure you book your hotel rooms soon for an exceptional discount.

Below is the official announcement:

Cost: $1200

Included: breakfast, lunch, breaks, power, wifi

Dates:

Instructors: Hugo Duncan, Antoni Batchelli

 

Prerequisites:

  • Basic knowledge of Clojure is assumed (this class will not teach Clojure)
  • Comfortable with installing and building open-source software.
  • Knowledge of configuration management systems is not assumed.
  • Bring your own laptop (computers are not provided).
  • You should have the following software installed prior to the class:
    • Clojure 1.3
    • Preferred editor set up for Clojure
    • Leiningen

Course Description:

Learn to use Pallet from the library's primary developers.

If you care about building infrastructure as code, for deployment locally on fixed infrastructure or to public and private clouds, then Pallet is the tool for you.

Pallet is a library for building infrastructure automation. Built on many of the principles of Clojure, Pallet uses functional programming techniques, such as composition, to support creating high level abstractions over different cloud providers, OS distros and versions, package managers and tasks. Using Pallet, you will code your infrastructure to directly express the components of your system, so that it can managed and scaled easily across OSs and cloud providers.

Pallet lets you:

  • Apply all your software development skills to managing your infrastructure.
  • Write re-usable infrastructure components, that can be used from development through to production, on local virtual machines, or on the cloud.
  • Make infrastructure and deployment an integral part of your applications.
  • Eliminate the low level work of maintaining the connections between the servers in your architecture by leveraging Pallet's first class support for discovering connection details at configuration time.

What will you learn?

How to code your infrastructure in Pallet. The course will be hands-on. You will learn Pallet by starting and configuring virtual machines, on a real cloud, implementing some common components.

Topics:

  • Functional infrastructure: Learn how stateful infrastructure can be built using pure functional programming.
  • Actions: Pallet's actions provide a rich library of functions that form a language used to write code that will run on remote machines. Actions are designed to work across the whole range of operating systems supported by Pallet, giving you freedom to move between operating systems and versions.
  • Crates: Build high level abstractions by writing crates, which are clojure functions that call any mixture of actions or other crate functions.  You are familiar with building abstractions using functions in Clojure, and the same techniques are used when you write crates in Pallet.
  • Phases: when configuring and running your infrastructure, there will be many operations you will wish to automate.  We'll show you how Pallet's phases provide an open framework for you to automate as many tasks as you need, while taking full advantage of the composability of pallet.
  • Servers and groups: server-spec's in Pallet provide a mechanism for directly describing the configuration and operation of (software) server components in your architecture. group-spec's allow you to map the server-spec's to individual nodes. Using server-spec's, you will see how to code your infrastructure on a single vm, and then use the same server-spec's to deploy to a horizontally scaled cloud environment.
  • Stevedore: For some special cases, Pallet's actions may be too restrictive, and for these cases Pallet allows you to write script using clojure, enabling the use of all the rich data available about you infrastructure in arbitrary scripts.
  • Upcoming: Review the driving forces behind enhancements that will be coming to Pallet, and discuss how these will benefit you.

 

Our Y Combinator Experience.

Hugo and I applied to Y Combinator (YC) this summer, and we did not make it to the interview. End of story. But It was a good thing. 

We did not care that much about the funding part. Instead, we thought that YC could be some sort of business bootcamp for us, and that's why we applied.

During this process, I also got accepted to Startup School, a one day event also put together by YC with well known entrepreneurs and Venture Capital partners as guest speakers. This lead to me being invited to a reception at YC's offices where I met a bunch of other YC applicants in the afternoon, and then a bunch more of Startup School attendees in the evening.

It was good that we applied. It made us think about where we were with our company and where we wanted to take it. It also made us think hard about whether we wanted to get any sort of funding that doesn't come directly from customers. 

During the first part of the YC reception, I had the opportunity to chat with many teams that had also applied. The conversations were frank and open, everybody had hopes and a tingling suspicion that they wouldn't get accepted, something that I shared too. There was a sense of community.

The mood changed quickly when the Startup School attendees started to come. Now, these guys want to start a company, but for the large majority of them all they have done towards that goal is basically applying for Startup School. They were cocky, pleased to meet themselves and even condescendent. What a change of mood! Ah, and they all want to do a new "foto sharing app that lets you share the last party pictures with your circle of friends based on location" or something along those lines. They'll do whatever is the flavor du jour in the hopes of getting funded.

It was good that we applied for another reason. I got to go to these YC events and get a feel of the kind of community we were applying to join, a community in which cognitive dissonance seemed to be the main currency. And I'll tell you why.

The main theme in the speaches from the YC partners and the Startup School speakers was that successful entrepreneurs in the valley had a vision first, and created the company later. Also that successful entrepreneurs have stuck with their vision during all the long times in which doing so was against the trend. And finally that successful entrepreneurs were the odd kid in the class. They even went to say that if you can avoid it, do not take money from investors.

But then everybody that I met thought all these statements were not applyting to themselves, because their new "social network" was truly different, even though they just started it 3 months ago and they had "pivoted" 3 times already. And by pivoting here they mean "we changed our vision".

Most shockingly, the guest speakers themselves did not seem to be aware of the irony of talking about uniqueness --when they have setup a university-like program which inevitably generates a great deal of uniformity-- and vision-- when founders were asked to abandon their ideas and do something else instead, thereby defeating the mantra that the vision should come first and the company will come later. 

So in the end, I started thinking that we are better off on our own, event to the point of almost fearing that if we made it to the interviews, we'd get excited and join the program --even if this was not the best for us. Luck would have it that we did not have to test ourselves this time, since we did not even make it to the interview.

In any case, here are my personal takeaways from all this process (some unrelated to the above):

  1. It is always problematic to take all your feedback from intermediaries and not directly from customers and potential customers. VCs don't know better than you do. They have tons of money and what they do is to lay their chips on the roulette table, but they know as much as you do which number is going to be the winner next. Scratch that; you know better than they do.
  2. We need to continue trusting our guts and go with what we think will make palletops win. Nobody knows better that we do.
  3. We have nothing to worry about other than the long hours ahead of us. We're in good shape (compared to what I saw).
  4. We are the ugly duck in the valley, and so are most of the companies that end up succeeding. You know what's not an ugly duck in the valley today? A social network, with photo sharing, and gaming mechanics, and mobile. Regardless of VCs saying that they look for original ideas, they won't fund an ugly duck, they'll fund a social network mee-too/wannabee instead.
  5. We need to live more in the shoes of our users. And we are our users. We need to think in terms of ourselves before writing pallet: would we have use pallet then? 
  6. We should keep applying to YC; I want to turn them down at some point :)

And this, my friends, is the truth

"A man may desire to go to Mecca. His conscience tells him that he ought to go to Mecca. He fares forth, either by the aid of Cook's, or unassisted; he may probably never reach Mecca; he may drown before he gets to Port Said; he may perish ingloriously on the coast of the Red Sea; his desire may remain eternally frustrate. Unfulfilled aspiration may always trouble him. But he will not be tormented in the same way as the man who, desiring to reach Mecca, and harried by the desire to reach Mecca, never leaves Brixton."

Arnold Bennet, "How to Live on 24 Hours a Day", 1910
http://www.gutenberg.org/files/2274/2274-h/2274-h.htm

Manning's MEAP as a progress bar

Manning is a computer book editorial that allows you to purchase early-access versions of their books as they're being written, known as MEAP. This is a great way to engage with the readers early and get feedback from them at a time in which the book can still be changed. 

Over time Manning has been doing a lot of book promotions by offering deep discounts for books in the MEAP phase. I have been buying tons of them. One of the cool things about MEAP books is that every now and then you get an email update with a new version of one of the books that you purchased. It's like a continuous Christmas!

Nowadays though, an interesting thing is happened. I moved away from my old java-spring-hibernate self, into the Lisp and Clojure and cool stuff world. And I did it in a clean-cut way. I quit my job, sank my head in books and blogs and Emacs, and finally emerged out of it with plenty of projects and even customers. 

But I keep getting MEAP updates for books that now seem ancient to me. Every time I get one of those updates it happily reminds me how much I have progressed in the last year or so. I feel like I am in a different universe altogether and that somehow somebody keeps sending me Cobol books... good times!

On e-books and why pragprog.com got it right.

For someone like me that reads computer programming books, e-books are the way to go: they're cheap, you can read them in your computer and they don't take shelf space. But things are not yet too mature in this space. For example, DRM in e-books is still pretty pervasive and diminishes the value of such books in a very important way: your computer cannot index their contents and thus they won't be taken into account when you're searching for something. That defeats all the advantages that an e-book has over a traditional book! The mobile e-book world is even more in flux. I bought a Kindle a year ago. I initially purchased a few books, and I tried to read them. They were mostly business strategy (borderline self-help) books, so lots of text and no graphics. Then I moved into buying books more related to software architecture and design; here is when things turned ugly. Kindle doesn't display tables at all. Some editors turn those tables into an image, but then the image's resolution is very low and Kindle doesn't offer a way to zoom into images. Also, Kindle cannot correctly display code, as it mangles with the fonts and the layout of the text. Finally, I cannot read a Kindle book in my computer; that's silly to no end. But then comes Pragmatic Programmers and provides FOR FREE to all their customers a Kindle version of all the PDF e-books bought at their store (I have bought 10). No DRM. Now I can read their books in my computer, in my Kindle and my iPhone with Kindle for iPhone. Now my Pragmatic Programmers e-books have become 10 times more useful and thus ten times more valuable. That also means I am 10 times more likely to buy my next e-book on software development from Pragmatic Programmers than from anyone else. To make things better, Pragmatic Programmers also offer another electronic format that lets you read their books on the iPhone that rivals and bests the Kindle book reader. Using Stanza for iPhone you can reach e-book heaven. Now when I am waiting for the train or in the train, I just whip out my iPhone and start reading a book right away. Here is the thing: e-book publishers, please drop DRM from your books. That silly DRM is easy to crack anyway. Make your books 10 times more useful, and you'll sell way more of them.

Are Ruby and JRuby groovy enough?

So now that Java seems officially dead (that is, after Sun buried this year at JavaOne), one should start looking at what language will take Java's crown as the CoolestUsefulLanguageOnEarth(tm), the one that will re-shape the Internet. Granted being cool is not enough for a programming language to dominate the world. Lisp is very cool in my opinion. ML is the coolest thing since slice bread. Way cooler than, let's say, Ruby. We're talking about languages made in the 70's and the 80's here, and they are still cool. Smalltalk is cool too. None of them ended taking over the programming world. Being cool and useful seems to give a language a chance to world domination. C was really cool at it's time and quite useful. So was C++, and of course, Java. Their usefulness was always evident by the fact that these languages are very pervasive, and that they let you develop a wide range of applications. Being useful is not enough either, although it provides a language a longer life than just being cool. Cobol is very useful. Fortran is very useful. VB is very useful. But, no revolutions happened with those languages. They are very pervasive though, but you rarely see them anymore. Well, so the story goes that cool and useful languages, at some point in their life, they stop being cool but keep being useful for very long time. Java is definitely not cool anymore, but very useful. People will continue to develop large business applications with Java for a couple decades, the same way people still use C++ today. So what's next? Some say Ruby. Some say Python. I say Groovy. Ruby is a very cool language. There is actually nothing new in Ruby, at least nothing that we haven't seen in other languages before (30 years ago?), but the language seems to have the right combination of features. Indeed, Ruby would not be cool today if it wasn't for the birth and posterior exponential growth of Rails. Rails is a very clever web development framework for Ruby that allows to build web applications in a very fast and agile manner. Rails is a RAD without an IDE. Both Ruby and Rails are very powerful tools in the right hands, and right now, Rails developers are very smart people that see eye to eye with the Ruby/Rails developers. I am not so sure Ruby/Rails is so useful. Here are some open questions about Ruby/Rails usefulness:
  • How does 5 years of Ruby/Rails legacy look like?
  • Once the excellent first crop (class A developers) of Ruby/Rails developers is exhausted, will the next batch of developers (class B this time) be able to properly deal with such amount of power in their hands? Mind you, class B developers amount to 95% of the developer population.
  • Rails dictates a "shared nothing" architecture as means to achieve scalability. Can all types of web applications be built around this concept? Is this a hammer looking for nails? ;)
  • If I want a Ruby based application to run faster, what can I do?
Python?... I love the language, but so far, not very web oriented. JRuby? Mmm... that's an interesting one! From the language perspective, this is Ruby. And you can write Rails applications on it. Sun has done it pretty sweet to fix the need for a "shared nothing" architecture, by allowing Ruby to run inside the Java VM and also inside a JEE web container. The nice thing with JRuby/Rails is that you can use all the available Java libraries from a Rails application. And this is really useful. The caveats? Questions 1 and 2 from the paragraph above. Groovy? Well, as a language, Groovy has taken a page (or whole sections I would say) from Ruby's book. Groovy has many of the features that Java lacks but that Ruby has and that make Ruby so cool. The difference is that Groovy's goals have always been to be "java-like" and also to integrate really well into the Java platform. At this Groovy is better than JRuby. Groovy also has Grails, which is a Groovy based framework very similar to what Rails is for Ruby. The nice thing about Groovy/Grails is that they can be used in close collaboration with Java/Spring. For once, Grails applications are Spring applications and they can use all Java libraries seamlessly. So you could write your kernel classes on Java and the more abstract code (also, the code more bound to change) in Groovy. The code that is executed the most times could be all Java, whiles the rest of the pages (admin, management, etc) could be done in Groovy. Now all of a sudden, you can have the coolness of Groovy with the usefulness of Java in one same package. Groovy seems both very cool and very useful to me. More than Ruby and JRuby. To the point that I'd like it to be the next language to take over the world as opposed to Ruby. Too bad that Groovy came in late, but I think it has good changes of toppling Ruby as the new King of the Languages. I think the real winner in the not so short future will be the language/framework that is best at seamlessly integrate both regular typed languages with dynamic scripting languages, and so far the Java/Groovy combination seems the best fit to win. I know that what I am saying is not very PC in the Web 2.0 world. Oh well, somebody needs to take stabs at looking at Ruby/Rails from the Engineering point of view!

At JavaOne 2007

I won't comment on my ability to keep this blog up to date. It's pretty shameless. I am at JavaOne these days. I'd say it has been disappointing so far, at least in the Java the language front. If you like scripting languages (as i do) then this is probably one of the most exciting JavaOne ever. No much word on EJB, JEE, Spring, etc... Quite a bit about JRuby, Rails and my favorite: Groovy. Groovy is now in quite a mature state. Of course it is not Ruby, nor it wants to be. But I am really happy to see that finally people are considering using scripting languages in servers (I' ve gotta say, Spring makes it very easy to use Groovy). Groovy is also ideal for writing unit tests and integration tests... But then, what about JRuby? Well, it rocks too! But so far it is not that integrated in Java, not like Groovy. But JRuby has a lot of potential, and the Netbeans support for it is pretty amazing. For when similar support for Groovy??? Lots of Ajax too. Lots of rich Internet applications. So more scripting languages, this time JavaScript. Ajax and Web 2.0 seem to be a nightmare when it comes to security though! In any case, I bought a lot of books on Ruby, Rails, Ajax and Innovation. None on Java. Java is dead from the language perspective. It won't evolve that much. It's pretty good as it is now and the trend seems to be to use scripting languages on the JVM when expressiveness and fast coding is needed. When speed is needed, Java seems a pretty obvious choice; unless you go to the "share nothing" architecture of Rails of course. Tomorrow we'll see James Gosling's gig... see what he has to say :)

LA pool party

So it was Mason's birthday and we all went down to LA to a pool party that Lisa and Fonda and all the LA crew put up together for Mason. It was an awesome party, too bad I had to leave early... too bad. You can see the pictures clicking the following image:
Media_httpphotos22fli_jjfoa

Long time no see ...

Well, that was embarrassing. My previous website died on me eight months ago... It has taken me some full eight months to put together a new one. This time, instead of hosting this site in one of the servers at UCSB I am having this site totally outsourced. The blog is based on Wordpress. I haven't done any fancy customizations, that's why it looks so boring. The pictures are hosted on flickr, and but they're also integrated in wordpress here. Life is good. Things are going well for me. Found the perfect partner, Anna. I am happy! :-) I'll be posting updates on my life regularly now that the site is back up. I'll be posting pictures too...