babebridou

Very satisfying post.

It confirms one of my opinions about proficiency in general. Proficiency has a lot to do with pattern recognition and having access to multiple tools, each tailored to solving a particular problem. Figuring out which tool to use for a given problem is a key aspect to proficiency, but the time it takes to carefully select the proper tool can often be trumped by simply choosing always the same tool and succeed or fail really fast. More often than not, the pattern matching after the first pass will be simpler because parts of the problem will be solved already.

I started thinking about it when I was a kid discussing the best football (as in soccer) players with my friends. I always favoured players who could use both feet and their head equally, able to figure out the path of least resistance every time, but one of my friends would say that the very best players would only use one foot, their best foot, and focus on their placement to maximize the use of it in every occasion. In other words, when the stars align they are unmatched, and their whole strategy revolves on making those stars align as often as possible, rather than on figuring out how to play on a given spot.

It made a lot of sense back then, as the one-trick-ponies could easily and consistently out-play the jack-of-all-trades if they had a whole team dedicated to serve their right foot as often as possible. I find it eerie that it still does make sense in the context of your game, and many others. When time is of the essence and wrong moves only cost the time they take to perform, you can either spend your precious time thinking of the correct play, or spend it doing something that doesn't require you to think at all, and adjust as you go using pattern recognition on smaller subsets.

I completely agree with you here. fullscreen web doesn't really work in 16:10, even in portrait. It's among the reasons why I preferred my iPad to my Xoom for web browsing a couple years ago.

Now I wish you could switch to portrait on this one and still keep the keyboard.

Exclusions happen, when you need to make do with libraries that have different release schedules or are poorly organized but critical for your current priorities, needs and time constraints. One should see exclusions pretty much as Technical Debt.

Maven becomes brilliant when you start dealing with a large number of modules and profiles, and becomes more tedious when you pass a certain complexity threshold, usually when you have multiple layers of compile-time code generation going on top of each other.

I picked the one with the longest distance between the T and the E. That was the wrong answer.

This quizz is an excellent training though. I didn't know anything at all about typography prior to taking the test (never bothered to learn the names of the fonts or their shapes), ended up scoring 17/20.

That was due to bad wording on my part, my bad.

I meant that one should accept that at any random moment the data might be inconsistent with the reality, but after the cut-off time the data for the previous period is guaranteed to be consistent.

IFRS and GAAP require real-time consistency? Because that's what I meant with edge cases, entries that are split between two accounting periods. You deal with them in eventually consistent systems just as you would in an ACID system: wait and interpret it when the data is complete.

Isn't accrual accounting the use of an account to log transactions at the time of sale rather than at the time of payment? If so the same technicalities apply, you can log your credits and debits in different accounts, no need for ACID transactions here, unless my experience in this area is flawed.

> Well good luck with selling your "eventually consistent" accounting system.

There's a reason why "eventually consistent" works in accounting, and that's the cut-off time. You don't require from your data to be consistent at every instant, but rather require that your accounting be guaranteed consistent at cut-off time, because that's the data that you base your reporting on. One way to guarantee that is to use only ACID transactions, but it's only one of many ways, and it has flaws (that might or might not be blocking depending on how distributed your architecture is).

In practice you can work around transactions in double-entry registers with UUIDs, and then fixing the inconsistent edge cases at reporting time.

"Moderately interesting"? This article is a gold mine on the subject!

I'd like to read his take on idempotency in logging system, as this has always been among the harder problems to solve when designing IT architectures for me.

Edit: Here are two more papers from the author, Pat Helland.

* Building on Quicksand - more about eventual consistency - http://www-db.cs.wisc.edu/cidr/cidr2009/Paper_133.pdf

* Life beyond Distributed Transactions: an Apostate’s Opinion - http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf

Actually they don't need to use transactions at all in accounting. All they need is a debit history and a credit history. Using transactions locally could be done but the resulting software would be far too complex for ATM hardware. Using transactions globally would be a huge performance sink considering their frequency over the world.

The only time I can think of that would involve a transaction (with a lock) would be when naming a credit movement or a debit movement for future reference (compensation for example), and even that can be "solved" using UUIDs with carefully chosen machine identifiers.

The result is a very asynchroneous, very distributed and eventually "consistent-enough" logging system. Just pick the right time to do your reporting (end of the month, end of the year etc), and accept that some figures won't reflect exactly the reality of the balance, since some compensations are done immediately (automatically) while others are performed, manually, days or week later.

The whole system makes it very hard to catch transactional events with certitude, that's the main drawback, since nothing proves that a given transaction was "real" and won't be compensated later on.

...and I use my gmail accounts to feed my Thunderbird.

I hate having to sign out/sign in every time I need to switch from personal to professional google account.

I tried to be careful with my wording so as to come out as neutral as I can on the subject. My intent was to turn this into a design discussion about the importance of carefully choosing default settings - I failed obviously :P

My personal opinion on advertising is very critical, very much like yours. It litterally cripples content quality for pebbles.

As a side note, I currently make about 100$/month with advertising on my mobile apps (~10-15k active users). I really want to switch to a paid product but I'm having trouble picking a correct price for it since I'm not completely satisfied with it myself. There are some mental barriers that I need to break first. Ads were an easy way out, I totally see myself in your pamphlet: a lazy and complacent developer, so afraid to see his pricing expectations shattered that he preferred to ship a free app with a bland and mediocre ad banner. Again, for pebbles.

The problem is that an ISP is altering legitimate content that it's supposed to serve to their customer by contract, that they took this decision unilaterally without suggesting a change in the contract, that the feature is opt-out, that this unilateral decision will reduce by ~10% the global revenue that companies can make from advertising to French internet users in 2013.

This is not a matter of being pro or anti adblocking, but rather about realizing how far the consequences of a default value can reach.

Just FYI, having a DUNS code is also part of the requirements for publishing on the Windows Store. Symantec is the third-party doing the verifications for Microsoft.

I might be going on a tangent here, but I can't help thinking there's something wrong with product names for the past few years. We're now naming things with incredibly common words, changing their very meaning into something else. Facebook, Touché, Bonjour, Spaces, Windows...

For some reason, it's creeping me out. I'm afraid to see one of those next big thing named Lundi, Ball, Tisch or Hora. It's like we're robbing our languages of their meaning, bit by bit, for commercial purpose.

We can do better than that, can't we?

Sometimes I manipulate a touch screen when I read a long and dense text but that's just to prevent the mobile device from sleeping.

The experience of going for an all-nighter is akin to watching a full season of 24 in one go, only you're the protagonist. It's memorable, and yes, especially if you manage to pull it off.

I tell it as a tale of inspiration: do it, once.

Whether it's good or bad for business/health/morale is a whole other story. Hint: it's not good.

Great, simply great API that just works. Keep up the good work!

What I would love to see now would be the ability to send compressed text to shorten the url.

Minecraft and Frontier EliteII conveyed pretty much the same feeling of absolute freedom, yes. Of course, Minecraft was based on a completely different premise - changing the world instead of exploring it.

It can be argued that there has always been a contrast between procedural games and handcrafted games, a contrast that has followed us since the dawn of game design. Procedural tends to mean lifeless, Handcrafted tends to mean depthless.

There is no longer a clear distinction between the two, though. Games tend to include procedural elements and interweave them with handcrafted ones. Procedurals are generally used to provide a longer game experience, while Handcrafts are generally used to convey a story or a designer's cut of fun.

A recent example could be Diablo 3. This is at the core a Procedural game. The game has been divided in acts, chapters and quests. Each quest ends with a handcrafted challenge, each chapter ends with a handcrafted miniboss fight, and each Act ends with a handcrafted "act boss" fight. Everything in between, including the fights, the rare monsters, the champion monsters, the stage layout and of course the loot, is procedurally generated. The designers have a set of game rules that dictate how and when this or that monster can spawn, how it looks like, and how, when, and what kind of loot it can drop.

For some players, this extends the game's depth and the fun they can get, from a dozen hours of handcrafted content to hundreds, possibly even thousands of hours of procedurally generated entertainment.

Another great example would be Skyrim. Again at the core, the Elder Scrolls series is procedurally generated, but with a twist; in Daggerfall, the third episode, they pushed the envelope to its limit with a really humongous generated world, of a size that only Elite games could surpass. With time they realized that they went too far; they had to restrict the procedural aspect and resume the handcrafting. Using the procedurally generated content as a mold, they could "paint" the game on top of it to make it feel more lively, possibly more epic with each following iteration thanks to a better engine and of course a bigger budget.

Then there's the opposite line of game design - those that start as Handcrafted with increasing amounts of procedurally generated elements as the franchise advances. The Dragon Age series is widely seen as taking this path (a mistake in my opinion).

For some other games that are pretty much only procedural, check The Sims, Sim City and their ilk, Dwarf Fortress, Audiosurf, NetHack of course, the Civilization series, etc. The whole line of EASports games could also be seen as procedurally generated as well depending on your point of view. "God Games" such as From Dust are also generally procedural.

Sometimes you're not calling or SMSing a specific person but rather a place or a community ("Is John with you?", "Is everything alright over there?", etc) Sometimes it's even weirder to have to choose between calling Fred or Julie whenever you want to chat with the couple and don't want or need to show a preference for either of them.

Anyway, we've been there already, and it worked for the most part. We used to have one phone in the kitchen, one in the living room, one in my sister's room and we would all be fighting to not have to be the one to pick it up whenever it rang.

But it worked, and it wasn't exactly "weird" :P

There is a specific and yet extremely widespread usecase for switching account on a phone: to distinguish between personal and business use. I'm a different person at work with my phone than I am at home or at a pub. I don't want to clutter my gallery at work with thumbnail pictures of last week-end debauchery, though I do want to see the whiteboard pics I took every day after each design meeting. The notifications I want to receive at home are not necessarily from some automated JIRA sender.

Moreover, I've been working on projects that are founded on the assumption that the device is "public" (for instance a phone wired to a bus stop) or at least "shared": the devices that, say, train operatives use, could be tied to the train rather than to the user. I believe we would all greatly benefit from multi-user accounts on the phone.

Something that also doesn't carry over this interesting approach is the land area. Paris is only 105.4 km2, New York City is roughly 7 times as large, Berlin 9 times and you could fit 50 Paris inside Istanbul as a whole. Those tiny segments are really, really tiny - they don't have the time to be oddly shaped over just a few dozen meters ;)

It irks me whenever a company takes a common word in a language and turns it into a name or a brand. It feels like the language is being pillaged.

Of course people are thinking about games right now. The first implementation I thought of was to reproduce the "hand seal/hand wave" spellcasting in traditional fantasy lore - and thus introduce a new genre of fighting video games: sorcery duels, also known as "Certamen" among Ars Magica fans.

Well, small-size icons are not going to be the source of the application package size issue, are they? I mean if pixel-perfecting 16x16, 32x32 and 64x64 icons is something we do already, using svg against the other end of the scaling problem (1024x768 -> 2048x1536) is a good solution.

You're right, that was my plan actually, but I got sidetracked by the cygwin beast, sorry.

I timed the fib(36) function from within a clojurescript repl inside a clojure jvm repl, and it returned in 86 seconds.

Then I timed the generated js function in a Chrome console with a not-so-minor modification so it would compile, it returned in 13 seconds. The modification in question was inlining the generated cljs.core.truth_(predicate) javascript function.

The orders of magnitude don't lie though - for what it's worth, a recursive fibonacci implementation in plain java returns in about 125ms (and depending on jvm warm-up, an array-backed computation is a merry jog of 50 to 300µs, but that's completely off-topic)

I have yet to setup gambit and clone the clojure-scheme project. I'm really curious though, I like these 800ms that the author advertises.

I wondered, too, so I ran the benchmark on a clojure repl on the JVM on my desktop, it timed at 1028ms.

I agree. The "big problem" is the low-ish revenue due to poor app sales figures compared to iOS, and probably nothing else. You can blame it on the device's architecture, I'd rather put the blame on the business itself and the way it works.

"Fragmentation" is an engineering problem that we can iron out. Bad market performance is much more complex and something that's in large part out of our control.

I'm currently on two missions. In one of these, we kick ass. Deliver on schedule or even in advance. It's scrum, we simply work as a team of four and ship, ship, ship, ship, feature after feature and fix after fix. We have our hands free, management is trusting our cell with the strategic future of their Tech tree, and we deliver.

In the other mission, I am not making this up, I spend 1hour/day on poor excuses of stand up meetings, 3 hours/day in various meetings, 1hour/day on various administrative tasks and 3 hours/day preparing powerpoint plannings for the meetings of the next day, and I'm a dev. I work with equally awesome devs in either mission, but in this one the customer is absolutely crazy inefficient and a control freak, and the best example of what NOT to do with scrum I've ever seen.

So who is more competent? The me that's killing it with scrum in the first mission or the me that can't do anything because of scrum in the second mission?

There's the matter of the veteran having more problems to solve than the novice, so they tend to dismiss different things as "unimportant", for better or for worse.

In front of the exact same code, the veteran will bring forward issues such as deliverability on schedule, integration, letting the end-user start the program at 4pm and still be on time to grab the kids at school, the amount of paperwork and convincing that needs to be done so that the people at marketing can understand the new tech well enough to actually sell it to a customer or so that the people at IT can properly install and maintain it on a production environment without calling him every other night.

The novice will say: "why is there a break in the pattern here?", "this code fails when x is negative", "this monster piece of java code looks like what I saw someone solve with a one-liner in python last week".

Putting them both in front of a screen from time to time might either get you the best of both worlds, or hours of painful & pointless arguments.