The Changelog: Software Development, Open Source - Scripty2, Zepto.js, Vapor.js (Interview)

Episode Date: October 26, 2010

Wynn caught up with Thomas Fuchs to talk about script.aculo.us, Scripty2, Zepto.js and the future of Prototype.

Welcome to the changelog episode 0.3.9. I'm Adam Stachowiak. And I'm Winn Nevelin. This is the changelog. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also on GitHub. Head to github.com slash explore. You'll find some trending reposts, some feature reposts from our blog, as well as the audio podcast for your listening pleasure. If you're on the Twitter, follow Change Log Show.

Not the Change Log. He's pretty cool, too. And I'm Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N. Fun episode this week. Finally getting to air our conversation with Thomas Fuchs from Scripty2, Scriptaculous, Zepto,

VaporJS, all things JavaScript. Yeah, this VaporJS framework is really, really awesome. Yeah, it's like the Uber JavaScript framework, and it's the lightest weight JavaScript framework that you'll ever find. It's been forked how many times now? I don't know, upwards of 300, I guess.

And it's got support for everything? Everything. And we also have you back from the UK. I am back stateside after seven days over in the UK, taking my life into my own hands, riding with a buddy that was driving on the wrong side of the road the whole time. So plenty of flashbacks to European vacation when he goes around the roundabout. I saw that video you posted on the roundabout, too.

Yeah, that magic roundabout. You know, that's the five-way roundabout. You know it's magic when the actual street sign says, The Magic Roundabout. I was pretty lost just watching the video. I didn't know where they were going. I have no idea how those guys do not have more traffic accidents than they do. Yeah, I was certainly amazed.

Like, insurance rates should be so high over there for sure. Oh, I know. I guess the only saving grace is the cars are so small that it's easier to dodge each other. That's probably it. That's probably why they get away with it. So I love the country. Not so much sold on some of the products they sell over there, like pourable yogurt.

This is what I guess is popular to pour on cereal and stuff. So not exactly sold on that one. And the internets are quite dodgy for the Wi-Fi. But other than that, my first time in the U.K., I really, really liked it. And you got the U.K. badge in Foursquare. Or not Foursquare, because you're anti-Foursquare. You're a Gowalla fan, right? So you got that U.K. badge.

I'm such a geek. I probably paid out the wazoo on the data plan to do a Gowalla check-in at Stonehenge. It's a shame how hard I'm laughing inside to know that, too, because we've been on road trips. We've had to stop places just so you can get a check-in going on. I know. It's who I am. That's who you are. Well, we love you anyways.

We're happy, extremely happy to have you back. So glad you made it back safe, and I'm glad you had fun. Had a ball. Fun episode this week. Should we get to it? Let's do it, man. Hi, we're joined today by Thomas Fuchs from Scriptaculous fame. Thomas, for the folks that don't know, why don't you introduce yourself and let them know who you are. Hello, I'm Thomas. Thomas Fuchs rhymes with books.

I am the author of the Scriptaculous JavaScript framework, which originated in the Ruby on Rails sphere about five years ago, together with Prototype.js. At that time, I also was a core team member of Ruby on Rails. I'm no longer a core team member, but I'm still doing a lot of JavaScript. I guess I'm here in the show today to talk about that. Yeah, we want to talk about Scripty 2. Give us the lowdown on the next evolution of Scriptaculous. Yeah, so Scripty 2, the most important thing about it, it's very slow in the making,

but we like to take our time and only implement stuff that we actually use on real-world projects. We don't want to implement really big, bigotry frameworks that no one actually uses for code. So sometimes it's coming along very slowly. But anyway, it's a complete rewrite of Scriptaculous, and if you use Scriptaculous, you know that the central part of this is the effects framework, and that's been completely rewritten to take advantage of things like prototypes,

custom events, and stuff like that. It's written for extensibility and easy-to-read code. It's a bit more for both than other code I write and other projects I have. But it's there for you to take and extend

and mess around with. And it also has really, really good documentation because this was something that was bugging me from the first version of Scriptaculous where we had a wiki and then the wiki got shut down and then the wiki, we put it on someone a wiki and then the wiki got shut down and then the wiki we put it on someone else's service and then the service was abandoned

and you know, it was quite crazy. But yeah, the main focus of Scripty 2 is a completely new effects framework with a modern one using modern JavaScript techniques very extensible. It's also usable for things that are not DOM nodes only using modern JavaScript techniques, very extensible.

It's also usable for things that are not DOM nodes only, so not only CSS-based animation, but you can use it for, for example, you can tie it into Rafa LJS and use it for SVG-based animations, or you can do animations on Canvas with it if you extend it in the proper way. But the basis of it is just a timing and a queuing framework for visual effects.

So still built on top of Prototype.js, right? Yes, it still works on top of Prototype.js. So a question from Twitter. Johnson Page asks, what's the future of Prototype in your opinion? With Prototype, we have some of the same issues where it's going quite slowly. However, it works very well.

I use it in all of my projects, basically. It still works fine. We actually just released candidate 3 of Prototype 1.7, or 1.7.1, and that brings us IE9 compatibility because IE9 now comes with finally a DOM-compatible events framework. That's the most important part about it

for prototype chess. So it's going along. We're still planning to release a prototype 2.0 at some point. Of course, no roadmap or no time on that date. But the main thing about prototype 2.0 will be that we're moving away from a prototype extension for anything that's DOM-related, because that has proven to be a bit brittle in the past and very hard to maintain.

It works, but it comes with a lot of disadvantages. So we are moving to something where we will no longer extend DOM nodes. But Prototype 2.0, for that reason, will break some compatibility with Prototype 1.0. But I think actually for Prototype, the most important part in prototype is not so much the DOM stuff,

but the language stuff. This is where prototype really shines with. If you have to do any sort of data munging or manipulate JavaScript stuff, you want the real class system, then prototype is a really good choice. It really allows you to write really, really solid JavaScript. And really allows you to write really, really solid

JavaScript, and especially if you come from Ruby, because then you feel right at home in Prototype.js. I was singing the praises of Underscore.js the other day. It's the framework that adds a lot of those features kind of based on a jQuery

model, and some guys kind of snickered and said, you know, we've had that in prototype for years. Yes, if you go to the underscore website, it actually says it's an extraction from prototype.js. So, yeah, it's pretty great. If you're using something else like jQuery or whatever other framework, and you want something for data manipulation,

and especially doing stuff with data in arrays arrays and you get some JSON data in, but you need to reformat it for something else, then Underscore.js is a really good choice. Or, of course, if you're using Prototype.js, you get all this sweetness built in right into your framework. So we've got a pretty young audience, and it's hard to believe we have a whole crop of web developers these days that have known nothing different than Prototype and jQuery. Talk a bit about the world before JavaScript frameworks and what it was like building JavaScript in the browser with IE and Netscape. Yeah, the so-called dark ages. Right. so before Prototype was really the first

like JavaScript framework that actually bundled a lot of functionality that before that you would find like very like very diverse spots on the internet you know of course there were those sites where you could download stupid things like

mousetrail scripts and stuff like that or the scripts that would run some sort of marquee in your status bar, and that sort of thing. But good quality JavaScript was really hard to find because lots of people

just thought it was this toy language and it's not really widely supported anyway, which was probably true at that point. So my first real adventures with JavaScript began when

Internet Explorer 4 came out. And that was the first browser actually that was like JavaScript and like DOM. I wouldn't call it DOM. It wasn't really DOM. It was like IE's version of DOM but that was actually really usable to

make like highly interactive apps and sites and at that point it was certainly the most advanced web browser available. Of course it was very limited from what we have today. And it was IE only and so on.

So it wasn't really usable on the web because most people used Netscape at that point. But for applications that were used internally or something, it was a great choice to use that. It was actually, in some ways, much more rapid to develop stuff with Internet Explorer than to use any sort of desktop-based native applications for lots of types of applications. So this is, I think, where it all started.

And JavaScript, at that point, wasn't really much different from the JavaScript we use today. JavaScript 1.5 has been out for ages, and JavaScript 1.3 before that, there's not so much difference between those languages. So you could have done a framework like jQuery or Prototype at that point in time, like, I don't know, 10 years ago. Have these frameworks

dumbed down the average JavaScript developer? That is a really good question. I don't think that they dumped down the existing JavaScript developers, but they certainly allowed in people that aren't really developers.

So, it's a two twofold thing, you know. It's good that the language gets more developers, but at the other hand, some of the frameworks, I think especially jQuery, have such a low level of... Barrier to entry? Yeah, barrier to entry, right? That you get people that are not programmers

and not developers, and they think they can develop, and you have to be very careful in that regard. You have to teach those people that they're actually dealing with a real language there, and there's really a complete language there. It's not only jQuery. You get a complete

object-oriented, really really nice scripting language there. And I think one thing today that is a problem is that no one really reaches those people and teaches them how to actually program. And that leads to a lot of bad codes in the end, I think.

You know, one of the things that I found rewarding is stepping out of the JavaScript frameworks and out of the least common denominator, you know, kind of facade we put across the browser differences. And if you target a certain mobile browser like WebKit or something on the iPhone, it really frees you to use the latest features of JavaScript. Yes, indeed. It's pretty awesome. But I would even step back from that.

And I would recommend just sometimes for some projects, just use pure JavaScript. If you have a little side project or something, try that. It's actually not that hard to write JavaScript code that even works cross-browser in desktop browsers. But as I say, WebKit is actually... I wouldn't even say WebKit on the iPhone is a very special browser. I would say WebKit is on most mobile browsers, actually, except for anything that's named Windows. So if you can target a framework for mobile WebKit browsers that will allow you to very, very easily replicate any bigger framework on the desktop, any bigger frameworks API, with very, very few lines of code.

And I just released something called Zepto. I mean, released. It's still in its alpha stages, baby stages. But you can still write jQuery-like code that just works on mobile WebKit browsers and desktop WebKit browsers. And the whole framework is like 2K compressed, which is like a tenfold improvement on size

over jQuery proper. It's been well received, so I guess the fundamental difference here is Zipto is kind of meant to be inlined instead of externally referenced. Yes, that's one of the ideas. I'm not quite sure if it's actually feasible because I think it will end up

with a little bit more than 2K of code, more like 3 to 4K, which is like two screenfuls maybe. But you can take the core of Zepto and just inline it if you have like a one-pager application because that will make the loading of your application really fast. Like say you have like an application that kind of mimics a native application doing some task, specifically some task,

and it also works offline and it uses local storage of some sort. Then Zepto is probably a really good choice because the user can practically instantly load it because it's so small from the code size. And then you go ahead and like load in your data and whatever, store it locally. And from that on, people will be able to use it. So the main idea behind it was like it was born when we did a site called everytimezone.com as an ad for our time tracking software Freckle.

We use that quite extensively in the changelog to schedule interviews. Awesome. That's great. It's good to hear. That site is a single HTML file. It uses, I think, one image, which is the ad. It doesn't use any other images or external CSS files or external JavaScript files. So if you go to everytimesoncom in a desktop browser

and look at the source, everything that's on the site is right there in the source. The CSS is inline, the JavaScript is inline. It uses some sort of early ancestor of the idea for Septo, like my ultra

mini pico tiny framework, which was basically five lines of code, like a dollar function, a function to set the inner HTML, a function to set CSS. That's basically it. And it was born there, because I could see,

okay, you can make a complete application with really only a few separate functions. And if you spin the idea further, if you use all the new and modern API calls and JavaScript API calls and DOM API calls in the mobile WebKit browsers, then you could work really massively safe on lines of code API calls and DOM API calls in the mobile WebKit browsers, then you could work really massively safe on lines of code while still providing a very, very useful API. And in Zepto's case, it's basically the complete core jQuery API that it provides.

You have a blog post on when you ported this to the iPad and some of the considerations for that, I found fascinating. So talk a bit about considerations for images and CSS3 and Canvas for a moment. Yeah. So CSS3 is pretty interesting because it allows you to use other things than image files for backgrounds. You can use gradients css gradients you could even use canvas elements as image backgrounds that you then can script from javascript and the thing is on mobile devices specifically the ios devices the web browser is is basically it it doesn't have much to do with

like a traditional web browser as you think of it. It's more like a high-performance 3D game engine. The elements on your page are actually textures in 3D space. And in my blog post, I didn't explain it that way in the blog post, but it basically works out like this. The more images you have on your page, the slower it will get because the more textures will be involved. However, if you have a sane amount of images and textures,

you can have very, very fast screen updates, rendering updates, because everything is rendered by the hardware. And that comes into play when you develop for mobile devices. If you have static images that are either image files or made with canvas or with gradients, and if you just move them around with WebKit Transform, for example,

then you will probably not experience any problems with rendering speed. However, if you move stuff around and at the same time change the DOM contents, for example, the inner HTML, the inner text of a DOM node, then WebKit has to re-render the element for each frame and

create a new texture and load it into the graphics memory chip and the graphics memory chip has to, and so on and so forth. So if you just move textures around fast, if you change anything about the elements, slow. We had a particular problem on every time zone. There's a slider which allows you to select the current time, and then the page updates based on that.

The slider shows the current time. So for each movement of the slider, we have to update the contents of the DOM node in there, which causes a bit of slowness. So because we couldn't change this particular aspect of the website because we wanted to have the time there, we decided

to look into what else can we optimize on the website. And it turns out that the biggest way, or the easiest way to make anything optimize on the website? And it turns out that the biggest way or the easiest way to make anything faster on the web, and this is even true for desktop web browsers, is to have as few nodes as possible on your page. We used CSS gradients and divs,

absolute deposition divs for the bars you can see on the background of the page, with each bar representing a day in some time zone. And I think there are 36 bars on the page. So 12 time zones and three bars each.

And for each bar, each of those bars, each of those 36 bars is basically a texture for the browser that the browser has to update and render and stuff. We replaced that with one big canvas element that we just now update. That turns out to be much faster because

the whole graphics chip just has to deal with this one big texture in the background instead of 36 individual textures. That brought a big speed boost into our application. There's some other CSS properties that

can cause performance issues because of the way the browser re-renders elements and has to re-render textures which is for example a box shadow causes performance problems and there's other properties,

but you can read about that in my blog post. You know, I'm convinced if you want to drive traffic to your site, you just mentioned HTML5 and Canvas in the headline. We posted an article this week about a little framework called, a little library called Jury that just provides a chainable wrapper to the Canvas object, and it's been highly popular. So are we at a point yet where adoption is to a point where we can get excited about Canvas? It just provides a chainable wrapper to the Canvas object, and it's been highly popular.

So are we at a point yet where adoption is to a point where we can get excited about Canvas? I think so. It's interesting that you mentioned it. The blog post I wrote about iPad performance, I think it has had like 100,000 page views now. So definitely there's a lot of interest in these technologies. And if you want to have really well-performing applications, mobile devices are slower than desktop browsers.

They have limited resources. So you have to understand more about how they work to make really well-performing web pages. If you just have a normal web page with some text and images on it, it doesn't matter. But if you have an application, it can start to matter very quickly if the user has a really smooth and nice experience or everything is kind of slow and jerky and lagging. So if you want to have the best experience for your user,

you have to understand how these devices work and how these mobile browsers work and how you can use all these new technologies like Canvas Elements and CSS-free goodies and also new DOM and JavaScript features. If you understand all of this, you can make web applications for mobile devices that just work so much better. You know, our industry tends to find buzzwords to rally behind. I remember it was DHTML back in the day, and then it kind of morphed into AJAX, and now the latest buzzword is HTML5. What does HTML5 mean to you?

HTML5, for me, I do know that it technically only means like this upcoming standard of HTML, but HTML5 for me is a technology of families which includes the HTML5 specification for the next generation of the HTML markup language. But it also includes for me all the improvements to JavaScript that are done, all the improvements to the DOM that are done, and also all the CSS3 improvements.

And other technologies that are extending the DOM, like local storage and geolocation and all that sort of stuff. It's a good word for defining the family of these technologies that are coming up now. You know, Canvas also. You know, I probably am not understating this. I think a little framework's come along to really change the landscape, and it really is redefining everything we thought we knew about JavaScript,

and that's VaporJS. Oh, yes. Yeah, VaporJS is pretty amazing. It's the only JavaScript framework in existence that is compatible with any browser that has ever been made and will ever be made. Even browsers that don't support JavaScript run VaporJS fine, which is a pretty amazing achievement if you think about it. We also have indefinite test coverage, which is pretty awesome. That is amazing. Yeah.

I think no other software project in history has had that. So that's quite an achievement, especially if you think that VaporJS was released after having four or five beers on the weekend of JSConf EU. I just noticed you pulled in a patch from Kenneth Reitz here on the changelog, so added XCore support. The really amazing thing about VaporJS is that it came together in just two or three hours after having lots of beer at JSConf EU last month. So that was pretty great,

all these achievements in that short a time. We also hold it like 140 forks on GitHub right now, I think. So it's been pretty popular. JSConf EU, give us a recap. Oh, JSConf EU is awesome. First of all, the organizers of the conference are just amazing people. It's like what they pull together in a completely non-profit way is amazing.

So it's really props to them for putting the show together. It was really great. Great location, lots of great people, very enthusiastic about JavaScript. You could really feel that there's something going on in the community with JavaScript. Everyone is really excited. And there was a really good mixture between server-side JavaScript

and client-side JavaScript stuff, which I find great because there's a lot of stuff people can learn from each other. As I said earlier, lots of people are drawn into to JavaScript by libraries and they don't really know what they're doing. Maybe they're designers and just

want to extend some websites a little bit. But the server-side JavaScript stuff actually draws in a lot of really, really good programmers to JavaScript. And this will help the language a lot. And you could see that at JSConfU, I thought there was a lot of great

talks there and content. My favorite talk was about that at JSConfU, I thought there was a lot of great talks there and content. My favorite talk was about FabJS, which was just a mind-blowing talk. I hope the video of that is up soon. Everyone should see that. It's like a really, really good example of

how you can take an existing language and completely rethink the way it can be used. I'm not saying I would use it next week or at any point, but it's a really, really well example of take something and just try to take a step back and rethink something. That was really, really great and awesome. And of course, I just released Chris Williams' talk on

Promote.js, which was one of the greatest talks I've ever seen in my life, I think, on a programming topic. It's so much really love went into this. You know, Chris is so enthusiastic and

excited about JavaScript as a language. And I think we all should be that. There's a lot of bashing going around. I do that a lot of the time. I really like to bash sometimes at things like IE9. I don't get Microsoft at all, I think. But there's also so much energy there.

And if you take that and channel that into something good instead of always lamenting and crying about that JavaScript documentation is so bad instead of sitting down writing JavaScript documentation or linking to good documentation so people can find the stuff and people get excited about JavaScript as much as we are excited about JavaScript

in the JavaScript community. Everyone wins. Absolutely. We're on board with that effort. So in the changelog, that's the Promote.js banner in the sidebar if you've seen that and wondered what that was. So server-side JavaScript,

does this have you excited at all or are you still slinging Ruby on the server-side? I'm slinging Ruby on the server side. I do like JavaScript a lot, but I also like Ruby a lot. And, of course, we have existing projects. There's no need for us to, like, change it over to JavaScript now because it's cool. But it definitely is a good thing that happens there because

JavaScript now as a language gets things like a common library and stuff on the server side so that's really good it's actually been around for a long time but it never really picked up until Node.js came along and I was there

when Ryan Dahl did his first Node.js talk, and it was amazing. So mind-blowing again. It's like someone sitting down and rethinking the way something works completely. It's just always amazing to watch that process, even if you do not have an immediate use for it. We might actually go ahead and use Node.js for an upcoming project where we have to deal

with a lot of real-time stuff like WebSockets and that sort of thing. And for these things, it really shines. For things where you would now use Ruby on Rails, for example, I think it might be a bit premature to just drop everything you have and just adopt Node.js. But for new projects, sure. I noticed you forked a project that we covered last week in the Chainlog, Eyeballs.js. Yes, Eyeballs is great.

It's from my friend Paul Campbell. And it's basically a clone of Ruby on Rails, but running in the browser using things like WebSQL as backend. So that's a pretty great thing to have if you have a more data-centric backend and send along JSON messages and stuff, and you want to render more in a templated way on the frontend.

That's something we have a use for in a current project, so that's why I forked it. I haven't committed back any patches yet, but I might soon. So what's your take on templating choices? Templating is interesting. It's, you know, if a developer is bored, the developer will develop either of two things.

One is a testing framework, or a second thing is a templating language. There's so many out there. It's like if you Google for JavaScript testing frameworks, I don't know, I think there's like hundreds of them. And for templating language, it's similar. And it's quite useful for a lot of things, but it won't solve all your problems.

You should never forget that you have a full-blown language at your disposal at all times if you do JavaScript. So you shouldn't try to get too meta. You know what I mean? That you try to put everything into the templating language and then you kind of have a language in the language. Not good. So it should be very basic if you use a templating language, in my opinion.

You know, one of the approaches is to start putting your templates in script tags with just an alternate language declaration. Do you follow this approach at all? I don't. I'm aware of it. And there's also things like CoffeeScript, for example, that kind of is a new implementation of JavaScript in script tags, and that gets re-evaluated. Personally, I like JavaScript too much that I'm a big fan of those other approaches,

but I can see that some people would prefer that, yes. So, templating, I guess a lot of the projects that you write, you write with Amy. So who handles the templates? So the way we work is, it's basically I'm the dumb programmer, but I'm pretty good with coming up with strategies to achieve the impossible, if you know what I mean.

But what Amy does is she has the ideas for the project and she does visual design and user interface design and user experience design. And concepts, she says from the other room. So I'm really like the dumb person in this team. So talk to us about Freckle and some of the partnerships you guys have done. Yeah, so Freckle,

that was our first big application together. And Freckle is a time tracking software. And the reason we wrote it is at the time, we did a lot of consulting. And there just was no good way to track your time with any web application or any desktop application, for that matter. They were all just too complicated,

and, you know, like a series of drop-down lists. And when you got a new client, you had to configure, like, half an hour, everything that you could actually start, logging time. With Rackle, we wanted none of that. We wanted that you can launch the application and instantly log time

because that's what the application is about. Everything else, the configuration of stuff and things that can come later. When you have time, when you sit down and look at the hours, then you can go ahead and type in a budget and that sort of thing. So it was really about the most efficient way

for the user to enter time. Nothing should get into the user's way. And this is where web applications can be really great. The browser is really a blank canvas. You can do basically everything in the browser. You're not subject to limitations that you have in native applications where widgets are not configurable and stuff

because you can just change everything around everywhere. That's the power of web applications, I think. You can really adapt and with JavaScript you can do anything you can think about in a web application. The problem that many web applications have is that people try to stay in some sort of standards-compatible mode or do not want to be too bold in doing applications. But I think that approach is not good.

That approach only leads to boring applications that look like every other application. If you sit down like this, if you look at every other time tracking application, if we would have done that at the point when we made Freckle, we would just have produced another application with drop-downs and you have to configure it before you enter time.

That's not the way great applications are made. Great applications are made by looking at what the user really needs and wants, and then you start everything from there, not looking at the other stuff. Maybe at some point in the development cycle later, you start looking at the other stuff and see what they do and what you do and compare a little bit. But when you start something, don't try to look at other stuff.

Just try to do your thing. I think that's important. And that's the important thing we do. We do not really listen to many other people. Otherwise, if I would have listened to all the people in my life that would tell me what to do, I would probably be still at university

and then I would be employed somewhere until I'm 80. You know, just try to do your thing. I think that's the most important lesson that you can have in life. So Amy's a big proponent of info products. I know you have some out there under your own name. You've written both printed publications and I guess e-books and what we would call info products.

What's your take on doing this as a developer? Yeah, info products has a really bad ring to it. It sort of has this sleazy aura. But info products are really great.

There should be a better name for that. Maybe nar is one of those words. It's just, there should be a better name for that. It's like, you know, maybe NAR is one of those words or it's just not good. It's not a good word. But, you know, a lot of developers and a lot of people we know actually make good money

by selling like PDFs or online courses and stuff like that. And it really helps people because if you, if as a developer, for example, you're looking for some information about, I don't know. I was looking for information about the Vim editor, for example, this week.

And so I got to Joff's site, peepcode.com, and he has a screencast on it. So I bought the screencast. It's the best way to learn it. And if you pay money for something, you're more inclined to actually pay attention because you're kind of, it's your hard-earned money

that you invest into, like, getting more knowledgeable about something. And when people come to my info product, for example, we have an info product called JavaScript Performance Rocks. It's an e-book and a little helper bookmark-led application. People go there because they want to learn about web performance specifically.

And they pay some money and then they get really, really good information that we took a long time to research. So it's a very fair exchange. And I think the web really allows you to self-publish these things without going through like a big publisher. Because the big publishers, what they do is they fuck you over. Sorry for my expletive. No, that's right.

You know, I came to the Ruby and the Rails world, and I think Amy's cheat sheets were instrumental in helping me grok some of the things, the terms and the concepts coming into that framework. And, you know, I've shelled out for a couple of your JavaScript eBooks. They're fantastic. I think it's a good value exchange on both sides.

Yes, definitely. Anything else in the stables from Thomas and Amy? So yeah, we are working on a new product for customer support because all customer support software sucks, basically. We tried everything, believe me. And it's all really bad. And most of these products, the most important problem they have is that they do not build a bridge between what the customers tell you and then what you actually implement in your software.

So we're trying to build something really, really great for that. It's called Charmdesk. And you can go to charmde.sk to sign up for our email when we will announce it. It says fall 2010. Probably we'll get the winter 2010 before we will announce it. But yeah. And we also have other products in the queue. So some of my closing questions were going to be

Emacs or Vim or TextMate. It looks like you're a Vim guy. I'm actually a TextMate guy. I just started using Vim this week because a developer we're working together very closely is using it and he's all about it. He's really excited about it. If someone's excited about it, I get interested

because I like seeing people that are excited about something. So I decided to check out Vim and I like it so far. I grokked the basics already. It can only get better from there. Of course, it has a really

steep learning curve and it's certainly not for everyone, but it does some things very well that I was looking for in an editor and with TextMate 2 being released I don't know whenever

yeah I don't know whenever Duke Nukem 4 is released you know I'm on the same Vim journey and I think we're probably watching the same peep code from Jeffrey with Smashing into Vim with the soothing voice of Dan Benjamin.

Yeah, it's a good one. It looks like I'm not the only guy that's looking for the perfect terminal font, too. So I noticed on your blog, I recently got turned on to Menlo from David Kaneda from the Cintia Touch team, and you found a variant of Menlo that you're really liking. Yes.

So Menlo is a great font. It's based on Bitstream Vera Sun's Mono, I think, which is an open source font. And Apple adopted that font as a new terminal font for Snow Leopard. And it's called Menlo. And some other people picked Menlo up and they had little gripes about it. You know, like the shape of the zero, for example. In Menlo, the zero is slashed. And lots of people prefer dotted zeros.

So people started to adopt the fonts. It's really interesting to see this sort of open source movement catching up into the space of typography and fonts. It's really interesting to see this sort of open source movement catching up into the space of typography and fonts. That's quite interesting, I think. And those people then put the fonts on GitHub

somewhere, and one of the fonts was called Mench, which was a variation with the dotted zero, but it also did some other changes that I didn't like, like it had bigger angle brackets, which kind of looked weird. But anyway, some other changes that I didn't like, like it had bigger angle brackets, which kind of looked weird. But anyway, some other guy

fixed another problem I have with Menlo, which is that the line hates, it's pretty dense if you use it in the terminal or in WIM for example. What he did is he made a little improvement or a little variance of the font

with bigger line heights, with like a small line height, medium and large, with more space between the lines. So I asked that guy to, hmm, this looks awesome. I really like your medium variation there. But I would also like to have the dotted zero

from the other font. And so he just put it in. And that's what I'm using now. And that's what my blog post is about. So it's awesome. Bash or ZShell? For me, it's Bash. But I haven't had the time yet to do ZShell yet.

So maybe I will switch at some point. This is the part where I now get to ask my guests what's got you excited about the world of open source and turn me on to new projects to go and explore. What got me turned on about the world of open source? I think at the time I was really getting into open source. I didn't even realize it. I got into open source because I was researching what else is out there except for like Java or PHP to make a web application. Because at that time, we were planning a web application.

That was in like 2004. And so I just researched on the internet, and I stumbled upon this Ruby and this Rails thing, and that got me kind of interested in it. And I checked out the IRC channel for it, asked some questions and like three months later I was on the core team of Ruby on Rails. So that was pretty quick. So I didn't even know what happened there exactly.

But since then I'm a big fan of open source and it's not good for everything. For example, I wouldn't recommend designing anything open source, like visual design or something. That just doesn't work well. But for code, it's really, really great. Especially if you can find projects where you have a benevolent dictator that really knows what he or she is

doing. And if you have programmers that just connect to you on the same level. I can remember having chats in the Ruben Reo's core team channel. We could talk about stuff that we wanted to implement in the framework, and we also agreed on what the direction should be. It was actually a bit scary to find people from all over the world to have exactly those same thoughts

but that's what's happened there so I can only recommend if you want to as a listener if you want to go into the world of open source and explore more and find a project that you can actually contribute to find something that you're really

excited about that you really really, really excited about, that you really, really want to make better. Do not try to get into a project just because it doesn't work. If you want to go into a project and really make it better, find something that you're actually

really excited about. There's so many projects out there, I'm sure there's something for you. What's got you excited that you just want to play with when you have some downtime? Actually, all sorts of gadgets and stuff. I just ordered a drone,

an AR drone, which I have been flying around the office. It's kind of dangerous, actually. But that gets me excited. I also recently completed my project of building the LEGO Millennium Falcon, the big one,

with the help of some friends. That was quite awesome also. So I like building things and I like creating things, even when it's not programming. One last question. I wanted to get an update on Schnitzelkont. Schnitzelkont, yeah.

Amy and me, we did a conference in September on bootstrapping businesses, especially web-based businesses in Vienna. to do this is because there's so many people out there that think they need venture capital to do software or companies or projects that's entirely not true we build everything we did without any venture capital or third party money it's all our money in there and we we weren't rich before we started this so we just did some consulting on the side and invested the money that we earned there into our own product products and that works fine and now we can live of our own products which is awesome and i can tell you that we can live pretty well uh of our own products so we wanted to spread this knowledge because there's so many people and developers and designers and entrepreneurs out there that always think they need to live up to

some idea of how it should be that someone else told them. You have to go to university and finish with a diploma or you have to finish high school even. You have to do this, you have to do that, you have to take venture

capital money or otherwise your company will fail on the first day. It's all bullshit. It's really, it's all about doing your own thing. If you really want to do your own thing, like creating a product for time tracking. Creating a product for time tracking that was in a space where there's like bazillions of other products out there. But the problem with those other products is they're all not good. The people that did those products

obviously don't care about their products or are just too dumb. I don't know. Maybe that was a bit too harsh. But some of them actually care. Some of

those products are not bad, but Freckle is better because we really care about the user.

That's our thing. We can make money and a profit by caring about users. Everyone's

happy with that. The users win, we win. Perfect. Any plans to make this an annual The users win, we win, perfect. Any plans to make this an annual conference? Yeah, we're actually planning a second edition of SchnitzelConf right now.

We're not sure about which format, you know, if we do it annually or every half year or we change cities or if we do, like, some sort of mini conferences in between or online conferences. There's all sorts of possibilities. But we definitely want to have more of those bootstrapping conferences

because we think bootstrapping is a really, really good option for a lot of people, especially in the web business with info products and web applications as software as a service because you do not need much money to get started. We started with a budget of maybe like $1,000.

It took us two months to implement the first version and we made money from the beginning. So that's totally possible to do. Same for info products. It's even easier. If you write a PDF about some topic you really know well, perfect. People will pry it from your hands.

They will pay your money for that because they want to know. Right now, if you would write a PDF about Node.js or a PDF about Zepto or a PDF about Vim, for example, there's no good cheat sheets about WIM. Write a good cheat sheet about WIM. People will love it

and people will pay you money for it. It's really not that hard to get started. And this is the thing we want to get across at the conferences. Good stuff, good stuff. Thanks for joining us today. Thank you. And I hope we get many, many more podcasts

from you guys because you guys are also doing a pretty awesome job. Thank you for that. Thanks. I appreciate it. See it in my eyes So how could I forget when I found myself for the first time Safe in your arms As the dark passions show