jpatte

[1] https://en.wikipedia.org/wiki/Ex_post_facto_law

Looking back at this it seems clear now that the way we used RavenDB (it could have been any NoSQL database) was not optimal and that most of the problems we faced were a direct consequence of our naive/simplistic approach. From a personal/technical point of view I don't regret the experience and I now have plenty of ideas about how to better leverage NoSQL databases, but from the business/customer point of view it certainly costed us.

    Purchased credits: %d.
    Remaining credits: %d.
    Buy more : 5 [link] / 10 [link] / 20 [link].

   You have purchased a total of %d credits and have used %d of them so far. You can buy [drowdownlist] additional credits by clicking here [link].

  <html:a href="/cats">Cats</a>
  <html:a href="/dogs">Dogs</a>
  <html:a href="/rain">Rain</a>

What would be the difference with "nullableVar ?? defaultValue" ?

  public static class Helpers
  {
    public static string UrlEncode(this string url)
    {
      //...
    }
  }

  // then later:
  string someText = "...";
  string a = Helpers.UrlEncode(someText); // valid
  string b = someText.UrlEncode(); // valid too

Is it just an impression, or did she get this sentence the wrong way?

The whole point of this saying is to make you realize that failure should actually not be such a big deal. Failure isn't an dead end, it's a step forward on the difficult path of entrepreneurship. Therefore, saying things like "I couldn’t fail. This was my baby, and if it was going to fail it would be over my dead body." can only lead you, indeed, to excruciating pain in case of failure.

Resilience is an excellent quality, and I think the only way to give your best and surpass yourself is by facing real challenges, but please remember that you cannot in any way resume 4 years of ultra rich/challenging experience with the two words "I failed". Jeez, just having survived 4 years in her very first startup experience is already a success.

I sympathize with her pain; I just find it sad that she doesn't seem to realize the incredible experience and skills she gained from this adventure. Those years were absolutely not wasted; the chances of success for her next startup are incomparably higher than for her previous one, and I wish her all the best for the future.

Edit: A startup is first a human adventure. After it "failed", ask yourself the right questions: - Did I learn something? Do I know better? - Am I a different person? A better person? - Did I help some people in any way? - Did my social skills improve? Did my network grow? - What about my legal/technical/managerial/whatever-ial knowledge?

If you can answer "yes" to any of these questions, than this adventure wasn't a failure at all. :)

Thrill me.

Bienvenue dans votre premier Spritz ! On commence par 250 mots par minute, un peu plus que la vitesse moyenne de lecture qui est de 210 mots par minute. Pas d'inquiétude, nous irons plus vite dans un instant. En fait, nombreux sont ceux qui lisent déjà des Spritz à plus de 1.000 mpm. A cette vitesse on peut lire un roman de 1000 pages en seulement 10 heures. Que se passerait-il si votre vitesse de lecture pouvait doubler, sans diminuer pour autant votre compréhension ? Et si elle pouvait tripler ? Notre but est de répandre les Spritz à travers le monde et que 15% du contenu littéraire mondial puisse être lu via notre méthode d'ici 2016. Sélectionnez une nouvelle vitesse sur la droite quand vous êtes prêt ou cliquez sur un des drapeaux ci-dessous pour essayer Spritz dans une autre langue.

Prochain arrêt, 300 mots par minute ! A cette vitesse vous lisez environ 25% plus vite que la plupart des lecteurs chevronnés. Un autre effet positif des Spritz est qu'au-delà de 400 mpm votre compréhension se met à augmenter en même temps que la vitesse après seulement quelques sessions de lecture. De plus, comme dans un Spritz vos yeux ne se déplacent pas d'un mot à l'autre ni même d'une phrase à l'autre, vous pouvez lire pendant de longues périodes sans les fatiguer. Cliquez sur le menu déroulant pour essayer une autre vitesse.

Voilà déjà de vrais progrès ! Votre vitesse actuelle est de 350 mpm. A cette vitesse vous lisez 40% plus vite que la majorité des gens. Vous n'avez pas besoin de cours de speed­reading ou d'exercices supplémentaires avec Spritz. Nous développons sans cesse de nouveaux logiciels pour que vous puissiez lire globalement n'importe quel texte avec Spritz. Nous offrons également aux autres développeurs la possibilité d'intégrer Spritz dans leurs applications. Spritz est de loin la meilleure façon de lire les livres électroniques, emails, sites d'actualité et autres sites web.

Vous avez maintenant atteint 400 mots par minute. Prenons un instant pour discuter de ce que vous venez d'accomplir. Après seulement quelques minutes, vous pouvez maintenant lire des Spritz au moins 60% plus vite qu'avant. Réfléchissez à la manière dont vous lisez d'habitude sur votre portable. Grâce à Spritz, plus besoin de faire constamment défiler les textes tout en lisant ni de pincer ou tapoter votre écran pour redimensionner le contenu affiché. Les éditeurs peuvent présenter leur contenu sous une forme compacte qui pourra être lue confortablement sur un téléphone ou une tablette. Spritz prouve à quel point les appareils actuels paraissent larges et massifs : vous n'avez pas besoin de tout cet espace pour lire du contenu !

Impressionnant! 500 mots par minute après moins de dix minutes. Si c'est encore trop rapide, redescendez simplement à 400 mots par minute pour votre prochain essai. Vous découvrirez que plus vous êtes détendu, plus vite vous pouvez lire et meilleure sera votre compréhension du texte. Nos études ont même montré que l'utilisation régulière de Spritz permet d'augmenter durablement sa vitesse de lecture et son niveau de compréhension, et ce quel que soit le support ! Nous croyons sincèrement que Spritz va changer le monde et nous vous remercions d'avoir pris le temps de l'essayer. Vous pouvez nous soutenir en nous "likant" sur Facebook, en nous suivant sur Twitter et en parlant de nous autour de vous !

https://github.com/madrobby/zepto/commit/3d92f20966aa02dee82...

Which means the OP genuinely thinks that commits like this one are good practice, and the purpose of the article is to show how to deal with it.

Yet as it was argued above, commits like that should never happen in the first place.

A project’s history is its most valuable documentation. (...) The quality of this documentation, however, relies heavily on the diligence of the people involved while writing commit messages.

Requiring such diligence when writing commit messages, while at the same time allowing the same people to write opaque code as shown in the example, would be absurd.

In short, maintaining a clean code base has always higher priority than maintaining a clean log.

I'll be blogging about it on GitHub.

Having a detailed code history isn't in any way an excuse to leave obscure code as is. If you have time to document it, you have time to make the code right.

For example,

  $(el).hide()

  el.style.display = 'none'

http://motion-twin.com/

My point is that if Om claims to be superior to other JS MVC frameworks - as it is presented as "the future of MVC frameworks" - it needs to be good (if not superior) in many aspects. Performance is a big deal all right, but another aspect (which seems essential to me) is that using this framework should be easy, concise and intuitive. And I've been kinda disappointed to see that the sample code given to present Om in action is not. At all. If I wanted to fiddle a bit with this code right now, to add a few features for example (like adding a timestamp besides each item indicating when it was created), I wouldn't have any clue where to start.

What bothers me is that Om has clearly been written with ClojureScript in mind, so in a way this framework is supposed to be sublimated by the language. It should "feel" right. And I know it's possible with other frameworks (and my comparison with Knockout+TypeScript was meant to illustrate that), so I expected it to be the case with Om.

Compare this with an alternative JS MVC framework (like, say, Knockout.js) and another modern "javascript-compatible" language (like, say, TypeScript), and see for yourself. [2]

While I didn't run any benchmarks, it's safe to assume the Om demo is faster. However which sample do you think is easier to write, test and maintain? If "The Future of JavaScript MVC Frameworks" is supposed to look like the Om sample, sorry but I'll pass.

[1]: https://github.com/swannodette/todomvc/tree/gh-pages/labs/ar...

[2]: https://github.com/jpatte/TodoMvc-Knockout.ts

Can't tell if the OP actually believes this or if the whole article is just a troll.

We make extensive use of Knockout and Backbone; the backend is ASP.NET MVC4/WebAPI.

Suppose you need a stapler for some work. You don't have one, but you know a colleague who does and who is willing to happily share it with you. You could go to her office, open the second drawer in her desk, take the stapler and leave. Or you could just ask her to give it to you. In both case the result is the same: you will get the stapler.

But there is a major difference : in the first case, you had to know where the stapler was. Your colleague knows it - it's her desk, after all - but because you decide to ignore the service she can provide and do it yourself, you have to know it as well. That means that you are both dependent of the manner of accessing the stapler.

What if someday she decides to move the stapler into the third drawer ? Because of this dependency, you would have to be informed of this change and start behaving accordingly. Your implementation would be impacted by a change in her implementation. And this is bad.

On the contrary, if you just asked her to give you the stapler, it wouldn't matter at all where it's stored. As the owner of this item she would the sole responsible for its location, and your behavior would never be impacted.

This is the purpose of encapsulation: preventing objects implementations from being impacted by changes in other objets implementations. You should be applying this everywhere, every times. Even for such small services as "give me that value, please". In your example, you should not need to know if a field or anything else is used to store the value because it's an implementation concern. You should just ask the value to the object.