BarCampMontreal3 report

I just came back from BarCampMontreal3. It was an amazing event! You really missed something if you didn’t came!

Here’s a remix of the notes I’ve taken from the (un)conference.

How data will save the world

Hugh McGuire delivered a great talk about two of his projects: LibriVox and DataLibre. Excellent talk, that started up the event nicely. I didn’t took notes at that time so I can’t quote quotes, you had to be there.

(Oh I think I missed a couple one here…)

RefactorMyCode

Marc-Andre Cournoyer presentation was boring… sorry about that. My computer crashed just when I plugged it on the projector. I had 5 minutes, so I improvised while waiting for the computer to reboot. But anyway, when I asked who knew about the project, a lot of people raised their hands, I was surprised!

JetFire

Looks like a new language with a syntax similar to Java and built-in workflow stuff. I didn’t really understood it. Seems like a framework for building web apps with customizable business logic.
John Hansen, from Jetfire, posted a comment pointing to this article for a short description of Jetfire.

Deploying desktop apps

Avery Pennarun showed with his banking app, how deploying can be easy with desktop app. He showed, installing and updating, all with a simple click. The cool thing is, he did all this without using InstallShield or anything. He built it himself and said it took only 300 LOC or so. Impressive! He said it’s as easy as deploying a web app. Well I not sure from the point view of the user, he still has to click somewhere and be aware of the updating process.

TimmyonTime

TimmyonTimeFrank Lamontagne and Dan Simard presented their project. TimmyonTime allows anyone to fill in timesheets and manage tasks by IM. Sadly they couldn’t get the thing to work even tough they had 3 backups solutions! Somebody shouted you should have called it Murphy, Frank replied they also tough about calling it GeorgeOnTime but it doesn’t sound so nice… They did a great improvisation anyway and also organized another presentation afterwards to show the thing.

CakeMail

CakeMail sampleFrancois Lane was next, announcing CakeMail public beta launch! The service, is for resellers only, it’s not branded. He had cool animated slides showing why they chose a cake as the logo and the name, because it’s all layers, API, something-I-forgot, plugins. It’s multilingual, has a couple of plugins for analytic, CRM and Google Maps. He also did a demo of it by sending and email to people registering to a mailing list live during the presentation, nice idea! Plus they offered cupcakes for lunch, they won me on that!

Keiky project

Evan Prodromou presented Keiki, a wiki for parents. After his success with WikiTravel and Vinisimo he was used to having free books and info. So when he and his wife got a baby he couldn’t travel that much anymore, that’s how he started Keiki.

Lunch

Lunch was free! Sandwich, vegetables and salads. Dessert was offered by CakeMail, as mentioned before.
I had great talks with Denis Canuel, Mehdi Akiki about Blitzweekend and with Duncan More about CakeMail and multilingual issues in software.

Startup Kung-Fu

Sylvain Carl
gave plenty of tips on how to start a startup in Montreal. 40 meetings rule, 40 meetings before anything happens, shit that’s a lot! One of his lesson was : Knowing what will be your features is not that important… Knowing what’s gonna happen next is more. Location doesn’t matter, it is possible Montreal, he met more then 10 VCs here he claimed.

TikiWiki

Marc Laport is a project manager of TikiWiki a wiki engine that is very active, top 20 most active project on SourceForge! Lots of documentation, he showed a 950 pages manual. Some features that make it different from MediaWiki and all are: builtin multilingual, better permissions, custom theme.

YulNews

Denis Canuel started with a quote claiming everyone is a journalist. He talked about his upcoming social news site. He gave a couple of hints on what will be the features by saying how timelines could be useful to display what happened around an event. But sadly he presented no demo, saying it was too alpha yet but still asked people to register for alpha on the site.

StickyCal

Erik Wright and David Lemieux presented StickyCal.
Learn about events before they happen, like music shows for example. It’s simple to setup, put an script tag on your page and you’re done. No authentication required and let your friends know you’re attending an event. It keeps the user on the band’s page. But again, no demo…

Notes on HTTP

Pierre Phaneuf was next presenting his guide on making your website faster with caching using Modified-Date or ETags, compression and a couple of others. One memorable quote:

The faster way to handle a request : don’t handle it!

I wish this came before I had to optimize RefactorMyCode. But he forgot to mention YSlow!

MercuryGrove

Scott Annan showed MercuryGrove. Basecamp-like web app. Really looks like Basecamp + Highrise + Backpack.
Not enough time and the app was too slow.

Coradiant

Quick talk. Big company. They install a box on your web server and you get detailed real-time stats of the visits on your site.

Raising angel financing

Austin Hill was next with a talk on how to raise angel financing. Raising is like dating. You need to build a relationship first, not like getting a girl in bar. Look for second time entrepreneur, look for sold cie in your field., target groups of angels. Convertible dept is the preferred way. There was lots of interesting questions after the presentation: What is an angel investor? anyone who invest in private cie, lawyers, 2nd time entrepreneur. 3-6 month to put and angel round. Don’t commit to long term things

I left, before the end, sorry for all the other presenters.

22 Comments

Filed under conference, montreal

22 responses to “BarCampMontreal3 report

  1. Maybe I’m too much of an cynic, but when the TimmyOnTime people said that they had videos, I said “oh, I bet they don’t have the right codec installed”. Sure enough… 😉

    YSlow seems pretty nice. You can already get most of this information from Firebug itself, but getting all of that summarized in a single report is much easier! From what I can see, my presentation was a subset of the stuff it’s based on.

    I also doubt that my “cheating” answer of “not handling it” is useful for RefactorMyCode (CDNs aren’t cheap!).

  2. I agree YSlow is just an agregation of info but it gives some directions. That helped me learn a lot about what makes a website fast.

    By caching the whole page to an HTML file your web server won’t hit your app server on the next request. Doesn’t that qualify as not handling it trick?

    Good presentation Pierre btw, loved it!

  3. Your comments on Jetfire are correct. It is a language that makes building collobrative applications easy including business Web apps. To help with the understanding I offer this short description of Jetfire – http://www.ottawatechcommunity.ca/wiki/index.php?title=Jetfire_Workflow_Scripting_Language.

    Yes, we recognize we could have done a better job of explaining Jetfire.

    I hope this helps.

  4. Hey thx John, I added a note in my post pointing to this article!

    I think you did a good job presenting. I found workflow framework very hard to understand. I also find MS Workflow foundation very confusing too so. How does your framework compare to the MS one?

    Thanks for the comment John and good luck with your project.

  5. Merci pour l’article Marc-André. Le démo officiel sera présenté lors du premier BarCampCanada en mars… Donc à suivre..! 🙂

  6. Woohoo! Super! et quand est prevu BarCampMontreal? J’ai hate d’en voir plus!

  7. losers

    barcamp montreal 3 was boring, and most of the talks sucked.

  8. I doubt you went, Amsterdam (http://ws.arin.net/whois/?queryinput=213.65.146.100) seems a bit far from Montreal

  9. Thanks!

    It’s true that you could do a kind of server-side caching by generating a static version of the resource on disk, then issuing a permanent redirect there, but that’s a lot of work (in the sense of there being a completely different code path from one request to the other), and you’d have to take care of expiring the cache yourself, and so on…

    If you issue a Last-Modified or an ETag header with your response, the web server will basically do this for you. Your app server should provide a separate phase for generating headers and generating the body of the response (I’m not familiar enough with Ruby on Rails and how it’s deployed, I worked more with mod_perl and writing Apache modules directly!), but what happens is that your “generate headers” function gets called, then the server sees that the Last-Modified or the ETag is the same, and it just doesn’t call your “generate body” function! Just make sure your “generate headers” function is as cheap as possible to run (possibly keeping the result of any database query aside for later, if/when the “generate body” function is called), and you’re good to go.

    The problem with Ruby on Rails’ automatic support for ETag is that it calculates the ETag by fully rendering the response and using the MD5 of that. It will indeed save bandwidth, but doesn’t save anything in terms of load on your server (and probably increases the latency for the client).

    ETag is something that is best generated in an intelligent way. For example, a blog engine could get the titles and last updated time stamps of the entries it would present on the front page, make an MD5 checksum that and use it as the ETag. This information would be very quick to obtain from the database in a single query (which would need to be done anyway to render the page), without working out the full details of the page and checksumming a larger amount of data.

    Or even simpler, in that same example, would be to just set the Last-Modified header to the time stamp of the most recently updated item. You see how those headers are very hard to provide in a fully automatic way, yet often extremely simple to provide by the application itself?

    You can read about this on Bill de hÓra’s blog (who is almost always incredibly interesting) here:

    http://www.dehora.net/journal/2007/07/earned_value.html

    And here’s an example of how to do it with Rails specifically:

    http://www.igvita.com/blog/2007/03/07/client-http-caching-in-rails/

    Note that this only causes bandwidth to be saved, but it still goes to the server. If you’re ready for the client to not even consult the server, you can set an Expires header sometimes in the future (maybe by an hour? even just a minute can be useful for people who go quickly back and forth between pages!).

    http://journal.paul.querna.org/articles/2007/06/06/mod_never_expire/

    Hmm… Maybe I should have made a blog article myself. 🙂

  10. Wow! What a reply! Thx Pierre!

    I don’t understand the use of the Rails article, Last-Modified header already does this and doesn’t touch Rails. Cache is stored in static html files and the web server automatically set Last-Modified on those.

    For refactormycode I use Nginx as the web server / load balancer. It’s really easy for setting up gzip compression and page caching.

    After your presentation I’ve also setup Expires header to 24h for images and max for js and css, as the filename change on each deploy. Page load time is under 1 sec (with cache) now! Wow!

  11. Nice review Marc!

    I just think that our demo was doomed from the start. It isn’t something that we could have knew.

    For those of you who are curious and are wondering what was the problem(s) exactly :

    About our first plan that failed :

    For some obscure reasons, it seems like our test account was blacklisted by our demo contact Timmy, this is why it never appeared online. Once the presentation was over, I reopened my laptop and just sent a “re/request authorization” message to the bot… and it worked.

    About the second option that failed :

    We then tried to add the “real” Timmy contact… but the problem is that our shared host is doing intensive reboots recently. Timmy was down at the time of the demo… bummer

    About the third option that failed :

    We then tried to load our video presentation “in the almost impossible scenario that everything else would fail!” . And then, we remembered that we had forgot to install the right codecs to play Avi files on our ubuntu distro.

    Morale of the story : Sometimes, shit happens and it’s okay. Nothing happens without a good reason. Right after our demo, a lot of people went talking to us directly to show us some compassion. 🙂 We also had the chance to make another (working this time) demo at 4pm. Dan told me : Hey Frank, at least people will remember us!

    About the Murphy joke, i just didn’t get it at that time. I was too in a “Oh god what is happening right here??” mood. That’s why my GeorgeOnTime joke had nothing to do with the Murphy remark. Some people found it funny anyway… so that’s ok. Sorry about that 🙂

    Anyway, this was a great event. And Marc, too bad that you had computer problems too (i didn’t even notice it)… but your presentation was definitely not boring. You presented the main idea of your application pretty well.

    So all in all, great edition of barcamp!

    Frank Lamontagne

  12. Pingback: Montreal social media optimization » BarCampMontreal3 part2

  13. Hey Frank,

    I quoted your reply about the Murphy joke because I was part of those who find it really funny, it had nothing to do w/ the remark but that’s what made it funny IMO. You did a good job turning all those unfortunate events into a joke!

    Dan is right, check this out: http://comingupforair.net/2007/11/03/barcamp-montreal-3/ you’re famous now!

  14. As I said, you can do a server-side cache yourself, writing to a static file that you can then refer to in further requests, and that the web server will automatically handle the Last-Modified and ETag for you.

    If that works well for your application, that’s excellent, since it also completely avoids touching the database or anything, and web servers (especially a very cleverly written one like nginx!) can do sending of static file with extremely low overhead.

    But as Phil Karlton once said, “There are only two hard things in Computer Science: cache invalidation and naming things”… If you do it with static files like that, you have to handle the cases where the cache becomes stale, if it grows too large, expiration of old entries, etc… Also, the requests to that content will not go through your code anymore, so you don’t get a chance to “change your mind” about the content.

    Also, there is now two levels of caching (one on your server, one in the client), which is more complexity. And we all know that complexity is evil! 😉

    What the Rails article explains is how to make the Rails page itself handle conditional GETs, basically just letting the client-side cache do its job without adding the whole caching machinery on your side. All you have to do is be able to validate (based on the If-None-Match or If-Modified-Since header in the request) the client’s cached data. So the extra complexity is only to pick between sending a 304 response (“not modified”) and a zero byte “page”, or sending the page as usual.

    nginx is pretty awesome, from what I hear. It’s pretty much exactly how I’d design a “serious” web server, if I had to do it myself (except I’d do it in C++ rather than C! but unlike very many people who use C rather than C++ “because it’s faster”, I suspect Igor actually knows his shit well enough that C *really* is better there).

    Immutable files with a new filename on each deploy is pretty much the very best case for caching (as you did, you just set it to the max!), that’s totally the way to go!

  15. Marc:
    To answer your question how does Jetfire compare with Microsoft workflows I think I should first answer why you might want or need a workflow solution.
    Here are 3 reasons for requiring a workflow solution for an application.
    1. Need users to generate the rules for how the application works.
    a. Application is one where this need cannot be easily satisfied by setting attributes.
    2. Application needs to run for an indeterminate/unknown period of time
    a. May be minutes, hours, days, months or years.
    b. Needs to survive computer crashes
    3. The application needs to collaborate with other users.
    a. Who may be on other platforms – PDAs, PCs, not just a Web browser?
    b. User may have separate roles.
    The 2 major differences between Jetfire and Microsoft Workflow Foundation is the 1) overall completeness of handling these requirements and 2) the base architecture. Microsoft WF provides base support requiring the application developer to perform significant work to complete the solution. Jetfire provides a complete solution out of the box for a developer so that he/she can start immediately developing their application without having to build a significant amount framework.
    The other major difference is in base architecture. Microsoft made a choice to adopt the standard “workflow” convention where workflows are broken into activities. Their xml language allows you to describe how these activities should be executed in the workflow. The activities are written by the developer in a .net language or are from their library. The end user develops the workflow by arranging the activities and providing “if” logic on which activity to execute under which circumstance. To achieve persistence the entire workflow is serialized to the hard drive.
    Jetfire is based on a pure Object Oriented implementation of workflows. Workflows are represented as instances of classes. The classes are written in language (Jetfire script) with strong roots with Java and C#. The language has first class support for roles, states, audits and several other features that workflow applications require. The end user develops workflows by writing or modifying Jetfire code using the library. The end user may write code directly or indirectly through a development tool. The developer can modify the library with their own classes written either in C# or a .net language. Persistence is achieved by serializing the objects and classes separately allowing them to easily migrate across different platforms (PCs, servers, PDAs).
    Hope this helps.
    John

  16. Hey thx John,
    Excellent info, especialy the 3 reasons for requiring a workflow solution for an application, I’m keeping note of this!

  17. Pingback: Back from barcamp montreal 3. | Yann Le Gouic Blog

  18. If you desire to take much from this paragraph then you have to apply such techniques to
    your won web site.

Leave a reply to macournoyer Cancel reply