dolinsky

OK, I guess I'll be the wet blanket that goes thud here, but I really don't see this being very useful. In fact, I see it encouraging bad practices. Maybe it's because I'm approaching this from the standpoint of a company that has more than a few users coming to the site, probably (hopefully?) has an existing release process in place and has multiple stages of their environment to go through (sandbox/dev/qa/staging/live). If this is how you slap lipstick on your pigsite, then you're probably building a site that very few people go to and you don't even have a local version of your site to test against first (because if you had a sandbox environment this tool is pretty much moot), in which case I can see the usefulness of this tool.

Not sure how I feel about the inclusion of the link/script tags in order to make this work but it all seems geared to someone who maybe has their own blog or very low-trafficked site and this would be their alternative to editing the files on the live server.

I've received mention spam in the past on Twitter, but last week it was used against me as a primitive DoS attack on my account (a DoS on my time). In a very short period of time after having tweeted something regarding the fallacy of vaccines and autism, I started receiving @mention spam from a user who was spamming all accounts that had RT'd my original tweet as well as me. Even if I blocked that account, a new one would pop up immediately after that and it effectively rendered my Mentions column in TweetDeck useless while this 'attack' was taking place.

It's nice to know that the accounts were quickly disabled but a more nefarious individual or group could have caused even more problems, and it does seem that Twitter should have some sort of prefiltering heuristics in place (if they don't already exist) to prevent this kind of abuse (new account / low # of tweets / low # of followers / consistent message 'n link being sent).

Yeah, I assumed the same, just throwing in a lil' parenting humor :) My wife 'n I looked at cloth diapers as opposed to single use diapers, and any potential cost savings were completely offset for us by the additional time/work investment needed by choosing a cloth diaper solution as well as the smell factor...there's ALWAYS a smell factor, regardless of how 'odorless' you're led to believe their bins are.

I don't know about you but I prefer to buy fresh diapers for my toddler :) In all seriousness though, my wife often finds buying in bulk at kids r us to be as cost effective as diapers.com is (YRMV obviously).

Android does do this from any screen, you just have to press the home button and hold it down, which will bring up the 6 previously used apps.

I find the 3 and 4 fingered swipes, especially on the smaller screens of the iPhone/touch devices to be pretty inconsistent and not very natural from a hand gesture perspective. I'd also suggest that 'more gestures' isn't what the average consumer is going to find as useful.

I'm also not looking forward to the first gesture requiring the use of my big toe.

What you consider ambiguous many users could consider extremely useful, and the beauty of having the soft key is that if you don't want to use it you don't have to. As for the 'level of destruction' that a back button would cause, it is up to the developer to properly save the state of the application whenever the state of the application / game changes. This isn't unique to Android AFAIK.

I'm not sure if you've used an Android device, and it is quite different from an experience w/ an iOS device, but the inclusion of a dedicated back button really is a welcome one IMO. You have to switch from thinking about the back button as 'go back to the previous view in this app' to 'go back to the previous thing that I was doing'. I think iOS doesn't go far enough to create synergy between apps here (and yes, Android can go too far in some instances) but the point is that the possibility is there in one and isn't in another.

There is a previous discussion about this from last night here http://news.ycombinator.com/item?id=2761427

That's exactly my point. It's a major fundamental difference between iOS and Android. The back button in Android can be contextual, while the back button in iOS only moves back between views in the same application. There are many times during a day where I switch between apps by clicking a link only to want to immediately return to the previous app, which is not possible in iOS (I first have to click the 'home' button or double click it to bring up the previously used apps bar and then select the app I want to return to).

I think the presence of a hard back button in Android is something that iOS is sorely missing. Whenever I switch from using my Droid X to my iPad I am constantly looking for the 'back' button, especially when installing an app from inside the Apple App Store (I find it very annoying that iOS kicks you out of the App Store and brings you to a seemingly random home screen just to show that it's now installing an app).

The back button in Android does have the fault of not always being consistent, but that is due to it being usable by the developer of individual apps. I find it extremely useful that I can be doing something in Tweetdeck, click a link which opens up my browser (Dolphin HD), view the full article, and then just press the back button to go right back into Tweetdeck. That's just not possible on iOS.

Also, long-pressing the back button in certain apps (like Dolphin HD) provide a nice shortcut to quitting the app (instead of keeping it running in the background), which helps on battery life.

I think that honesty is a two-way street, especially in this scenario, and too many developers wind up holding a recruiter over a fire for what the developer perceives as a dishonest/snake oil salesman approach when they themselves are often inflating the truth either on their resume or when talking about previous accomplishments (I was guilty of this early in my career as well).

Now I do my part to be honest, and I look for the same in any recruiter I come across. I'll echo Ed's sentiment in saying thanks and it's nice to read about recruiters who have a passion for the industry and the people in it and not just a passion for making the sale.

While I enjoy using MongoDB where appropriate, this example provided is somewhat of a straw man fallacy because it's missing the part of the transaction which decrements from the total number of each item available.

Edit: To address the issue of the total number decrement needed above, there is the two-phase commit, but then you're getting into something that isn't a transaction, by definition, and is more along the lines of eventual consistency.

http://www.mongodb.org/display/DOCS/two-phase+commit

The quote 'praise effort, not intelligence' isn't mine, though I probably should have used the word ability instead of intelligence. It's been born out of the numerous scientific studies done that continually show that by saying to a child 'I am very proud of the effort you put forth on X' as opposed to saying 'You're so smart! You studied hard and got a B instead of a C!' you are placing the emphasis on something the child has control over (their effort), over something which is innate (their natural ability).

I agree with you that learning to work hard is not a worthy goal on its own, but the praise effort vs ability debate isn't about encouraging a child to work hard but simply to praise them on what they have control over (their effort) vs their innate abilities.

Now, when it comes to child psychology and keeping a child engaged, maybe you're right and it's better to praise effort. But that should not come at the expense of praising intelligence; "intelligence" is the end product of many years of effort directed at the process of learning and thinking, not something that's doled out of a box at birth.

This idea of praising effort vs ability has been discussed previously here, so instead of repeating it I'll just link to it :)

http://news.ycombinator.com/item?id=2237874

http://news.ycombinator.com/item?id=2562632

Yes, but it's the kind I can appreciate. Instead of a 'hey connect with facebook and then go through my signup process as well' he's using FBConnect as the authentication backend.

Watchlr looks to do the same and more. Gregory Schnese gave a really good presentation at the most recent NYTM event this past Tuesday. You can sign up at http://watchlr.com.

Along side the findings reaffirmed in this study, I think it's prudent to mention the impact that language can have on a child's confidence. Specifically, the work done by Carol Dweck [1] and her colleagues have shown just how influential language can be in setting a fixed-mindset vs a growth-mindset in children.

In short, praise effort, not intelligence.

[1] http://en.wikipedia.org/wiki/Carol_Dweck

Both of these are quite the anecdotal statements to say the least. Not really sure what you mean by "of its kind", but there are plenty of other companies in the email marketing space, and to the GP's point we really have no clue why their blog went down (MC has been on the frontpage of HN in the past w/o incident).

TL;DR - this is no different from almost every other site that many of us already participate in that includes an aspect of uploading/sharing content and in no way does this imply ownwership.

To add to this...just because you have a monopoly does not make what you've done or what you do illegal.

It's what I spend all day using as well. The dev environments I've either implemented or been a part of (web centric envs) have all used local folders mounted to VMs that provide that painless and fast requirement you speak of while removing any pain points associated with varying platforms. You dont need to sacrifice the former to achieve the latter.

The goal should be to keep environments as similar as possible, which vagrant helps to accomplish. Just because you can develop locally on your Mac before pushing to a QA/Dev/staging environment doesn't mean you should.

Obviously your Dev environment isn't going to be able to match every aspect of your production environment, but keeping the same platform builds across environments is something that all teams should be aiming for.

If all you're doing is keeping a copy of objects in a memory store for quick retrieval you might want to implement a read-through caching pattern using Memcached (or Redis but I'd turn any persistence off). Most chat clients don't allow for editing of posts, so you could just use Redis as your persistent storage using lists and RPUSH.

Thanks, that makes sense. Is it often that these conflicts arise during development on a team of 1-3 developers? I'm also assuming you're referring to the package contents of the .xproj file (specifically project.pbxproj), correct?

Could someone elaborate on the difficulties encountered managing branches of an iOS project in XCode using git?

If you replace "especially when sorting by items in two directions" with "only when sorting by more than one item in different directions" above when talking about composite keys, then yes that's a factual statement of MySQL and something I believe Postgres supports.

The same composite index in MySQL can be used to do ASC-ASC and DESC-DESC sorts but cannot be used to perform an ASC-DESC sort.

I disagree with your beat down of Pandora. I find one of the most frustrating things about turntable.fm to be the lack of appropriateness of songs to their rooms genre (if we're going to compare it to Pandora). I can listen to a personalized Pandora channel for hours at a time while down voting a few songs. I find myself hitting the lame button in a DJ room as often as awesome because you're at the mercy of the DJ's taste.

I think the idea is great for what it is right now: a way for a group of people to get together and share some music with each other. I just don't see being comparable to Pandora.

I would love it if people would share their real world experiences with either (or both) Puppet and Chef in dynamic environments that needed more than a few servers to be maintained. In particular, polyglot persistent environments that aren't necessarily tied to a particular framework requirement.

Am I reading that correctly that you're sharding a database on the same box?

How is this related only to MongoDB?

Oh no doubt, and I think naming conventions is something that takes practice over time in this situation - too verbose leads to 'wasted' space, too little leads to making it near impossible for someone to view the database. Since indexes don't store the key names that does alleviate part of the problem as well.

I tend to leave the default _id in place as it also acts as a 'created_on' timestamp, saving the need to add an additional field.

Thanks for the deck. It's always good to hear about situations that didn't work out well and what can be learned going forward (though I do think you'd have a better experience using the 1.8 branch than you did with 1.4).