marcusf

Rich is of course relative here, but for your argument I assume you mean a middle class person in a stable, western socitety with a couchy job? :)

Note that I say that they might be an ethical negative, not that they are intrinsically unethical. But I believe for example that when Sweden exports weapons via middle men to Libya or Iran, that's a net negative. Also, boiling down the existence and services of "all of those beloved government institutions" to national defense seems very simplistic. Right now, there are a ton of factors beyond missiles standing between me and foreign incursion.

I guess it's a difference in perspectives, because in your lists I definitely see things that help society:

- Government provides services. Around here, it's healthcare, schools, universities, infrastructure, defense, a justice system, social services, plain governing, etc.

- The weapons industry might be an ethical negative, but they provide benefit to society in terms of basic research and R&D (not saying other things couldn't replace this -- I'm saying right now they provide this value)

- Paper/oil/meat/mining provides tangible goods that while depleting a finite resource pool still provides value today to scoitey.

- etc etc.

There's a book on how the marines does management called Corps Business [1], it makes a pretty decent argument for implementing some stuff from the armed forces, eg. adaption, steering by objective, breeding culture etc. It was a while since I read it, but I remember that I thought it was a decent book sans some needless glorification of the marine corps.

[1] http://www.amazon.com/Corps-Business-Management-Principles-M...

Might be preemptive then, they're aggressively building out LTE in Sweden (or at least here in Stockholm)

Very amusing :-) I imagine it was designed to and will go viral. Having no insight in to the french election, he seems like a bit of an outsider, though?

In general, it's interesting to see campaigns across the globe shifting to a more digital campaign strategy. The latest Economist issue had a note on how the Obama Campaign has spent $12m on digital, compared to $3m on TV and radio ads (http://www.economist.com/node/21552590)

Yup, seems like the hype took peoples common sense with it out the window. I'd assume and hope that just because there's a mongo api on the client, surely doesn't mean it's the raw socket that's exposed?

I'll gladly concede the point. It was actually more people running noscript than I thought, and for some markets (I'd also wager tech-savy ones) it might very well be a sizable chunk of users.

I think what the poster's implying that a website not working without JS is indicative of an incompetent team, though I might be reading him wrong.

Ok, so presumably somewhere in the vicinity one per mille of total users online. Actually more than I thought, and no doubt an important demographic for some types of sites.

I guess the only way to know how relevant it is to cater to noscript users is to measure how large a chunk of potential customers your leaving behind relative to the cost of fixing your site to work without JS.

Agreed. Something like a landing page requiring javascript in the first place certainly is bad form. For my comment, I assumed it as a given. I'm not sure how much time I should spend honing my <noscript> tags if my page doesn't work without Javascript at all. Seems there's bigger flies to swath.

Don't get me wrong: I don't disagree with the sentiment, I'm just saying I doubt I'd even put in the effort of redirecting them to a separate page of any kind if I'd decided that my landing pages should be very javascript heavy.

My prejudiced view is that it's such a small part of the population it's not worth caring about, though I'd be glad to be proven wrong.

If doing pages that require javascript to even run in the first place is a good idea, I think is a different discussion.

Honest question: How large is the noscript population? If I were to chose where to invest my time, catering to the noscript crowd would probably come pretty low on my list of priorities.

First of all, it's of course the Meteor team's prerogative to chose whatever license they want, and wanting attribution and pull requests is in no way an unworthy cause.

That said, GPL made me look twice. Mainly because client and server are so intertwined, that I assume the entire app would need to be GPL'd to use Meteor without getting a commercial license. Now I've nothing against the dual licens, and paying for a framework that makes us money , but before shopping Meteor around the company it'd be good to have some specifics on what they're thinking in terms of a commercial license model. I hope that's on their priority list. It's hard to motivate investing in something that may later turn out to be prohibitively expensive.

I was about to jump in and chastising you for generalizing about young programmers before I realized it's been 21 years since I wrote my first line of code, and I probably don't count as young anymore...

Though let me say that this is where I think good universities play a crucial role. A lot of my class mates had never written a line of assembler or C before university, and by the third year we had all built CPU's, compilers, operating systems and a few robots. Some of that is bound to stick and help you grow an intuition about the towering stack of complexity below the browser window.

I doubt the poster meant it as a recursive statement. Rather, if you work in Java you should know how the JVM works, if you work in Javascript you should have a good grasp of how the browser works, etc.

This is exactly why it feels so sexy. I took some courses in sensor fusion at university, and this is a very cool distributed application. Being able to create reliable "Bump-distance" vectors given all the variance with a distributed clock (though they seem to push the clock to the client in the browser), and with the position given by the browser etc. Very cool.

I was thinking in the case I'm standing next to him and just want to give him the file (I just photographed a whiteboard, for example). There's a ton of different, valid ways to send that file, but this is certainly one.

Yeah, that's true. I thought I wrote that as well but seems I erased it :) From experience, the accuracy on my browser location can be quite low, but I guess if you have (x,y,t) on both devices and a relatively large distance in the vector between bumpers it really doesn't matter.

This just very cool in a very nerdy sort of way. I kinda wish it was less gimmicky, on the other hand I assume bump uses the time stamps of the shake and the key down to figure out which two devices are trying to talk. I wonder what the threshold for collision is?

Anyway, very cool and I could actually see a use for this, sending photos of whiteboards to colleagues that don't run Mac/have an iPhone. Would have to compete with email/dropbox for ease of use, but it does seem very simple on the receiving end, just surfing to a web page.

I guess he was misled by the URL and title of the document, both of which say Manifesto and not manifest.

On a less snarky note (sorry about that), it seems like a good check list for putting together an event I'd like to attend. As someone else noted, none of the demo-parties and hackathons I've attended have ever checked off every box. On the other hand, it might be a cultural thing -- I imagine these events to be more developed around the valley where they're more common.

Not to pile on with the nitpicking, but for just the cases everybody here is talking about (eg non-crypto hashing) you get to "pick" exactly the hash function. You're forced, actually, to implement hashCode() in Java if you want to be able to put the object in a HashMap, HashSet, etc.

I'm not sure what the value of this post is? Would you honestly expect every company or even every demo day to contain a frighteningly ambitious idea? And if they were frighteningly, scarily ambitious, would TC really hype them? The sane response seems to be to write them off instead as far too ambitious.

I guess I just don't get what the skepticism here brings to the table? I'm open to input about that.

Sorry, 'months' was ill-chosen. FWIW, it's usually measured in hours where I'm currently at, but I've seen projects where people have spent literally weeks doing inane refactorings and rewrites, or where that has been the dictated norm ("We must rewrite our user management system, it's busted").

Who are 'they'? It might be that teams come from a more rigorous environment with project plans and imposed rules and were never given the chance to experiment with how they create software, or they might come from an environment without any rules whatsoever. Both work for a lot of companies, but usually you try something like Scrum because they don't.

A lot of times it requires a change of mindset where managers and executives have to relinquish control and trust developers to do what's right. That might not be the easiest thing in the world.

Then I don't get the hostility displayed in your original comment. Of course it's not a silver bullet, it's a set of tools for managing development together with a philosophy of work.

YMMV but we've used several agile ideas (for example iterations, retrospectives, stop-the-line) to great effect to reign in scope creep, increase quality, reduce overtime and make people happier, overall.

There's a lot to take offense to in this article and I wonder if the author has any practical experience with working within agile constraints or if he just picked up a book and didn't like it. For example, "In theory, developers are supposed to be interchangeable in agile/scrum". I've never seen that articulated in any agile literature. To the contrary, the agile manifesto puts "individuals and interactions" on, literally, its first line. It's ALL about people and finding ways for people to contribute to delivering working software.

Processes at their best are self-imposed sets of constraints that are empirically found to lead to better software (for whatever axes of 'better' makes sense for your team - faster, feature richer, higher quality, etc.) Scrum gives you a baseline set of rules to abide by. Any team who've worked with Scrum for more than a few months will start to tweak, add to or remove from these rules. If they're any good, they'll measure their tweaking and see what works and what doesn't. This is the whole point of having a retrospective.

As another example, if you want to include quantifiable performance bounds in your stories, do so. We work Scrum-ish, and we have a set of QA steps for every story implicit in its delivery (works across supported browsers, feels fast, immune to common security errors, etc). We test for this, and we demo it, but it's not articulated in every story. It's implicit in our work.

Not to be confrontational, but I'd wager that you've never developed in an agile context for any longer period of time?

> Don't rewrite code without consultation.

This is linked to a pet peeve of mine, especially with restless, young developers. There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". I don't know how many times I've seen someone go down the path of seing battle-tested code, not understanding it, thinking they can rewrite it better only to spend a month falling in to all the same pitfalls that lead to the original code. The middle road is of course refactoring. Cleaning up the code in small, discrete steps to something you can understand and work with is many times better than just tearing stuff out and restarting.

There's a good quote related to the Curse of Knowledge in a conversation between Daniel Ellsberg and Henry Kissinger as told by Ellsberg: http://motherjones.com/kevin-drum/2010/02/daniel-ellsberg-li....

Typeface design is as much art as it is anything else, and this is firmly in the art camp and not concerned primarily with legibility (kinda like an issue of Raygun). I like it, it made me smile.