ddagradi

"she" (or "they" if you're not certain) - the author is a woman.

Because you don't have a response other than to cherry pick sentences that sound bad out of context? Go right ahead, buddy.

You have a context that makes domestic violence acceptable? I sure didn't see it in your parent comment.

"Ask first" works just fine when the question is "can I stick my hand down your pants?". It really isn't the social norm to do that without asking.

According to the post, she was punished by the law for that (DUI). What else are you asking for?

GitHub is not a company involved in the business of midwifing. They are a company involved in the business of software development.

Is it not possible that the cultural imbalance in all of these fields is due to sexism?

[reposting stolt45's comment that got killed]:

Hey Ricky, we've definitely had some billing related issues recently. We've just finished the initial stages of moving onto a new system which should help clear up the cause of the issues like the one you mention in your last post. Sorry about the delays. If you email me at chris [at] heroku [dot] com and I'll make sure you're taken care of.

re: DNS CNAMEs, thanks for the feedback! I've updated the relevant section:

> This ensures that in the event of an infrastructure-level issue, core components can be replaced without requiring you to make changes to your apps.

You are right, it's not about protecting the platform from an app being DDOSed - that example was far too specific. It's about ensuring that an app is configured take full advantage of the flexibility and redundancy that our infrastructure is designed to provide.

Apps with > 1 web dyno are not idled. Please do open a support request if you think your app is being idled incorrectly.

You're right. It will be supported indefinitely through the gem - so neither officially deprecated or going away.

However, since .sass is no longer the primary syntax (nor default for Rails), and it's not supported by any new development efforts, it's safe to say that it is not the favored child.

Too late to edit anyways, but we're both right on this one. SCSS is a Sass syntax. ".scss" and ".sass" are both Sass files. Their docs tend to name the languages in titlecase, and the formats in all caps. That surely won't confuse anyone!

That syntax has been essentially deprecated for a while now. I think one of the most important aspects of SASS syntax is that any valid CSS3 file is a valid SASS file and compiles without error.

This can't be true of the indented-syntax, which has two downsides:

* It's a huge barrier to entry for anyone new to the framework when they already know CSS.

* It makes porting and/or incorporating existing CSS unnecessarily complex.

(The same things could be said about HAML, but people generally have no problem writing HTML, while CSS is still a fluid and ever-changing system).

The indented-syntax is way nicer to look at, but it's a good thing that it's heading off into the sunset.

"The horse-and-buggy has been working perfectly for the last hundred years, why rebuild it from scratch?"

Nothing is beyond disruption. Just because a technology is sufficiently functional doesn't mean there's no benefit to rethinking it.

It's not "5 lines", and it's not about "junior programmers". My designers need to work with my Rails apps, and learning the intricacies of setting up a Rails stack is not their job description. Just like maintaining their dev environment isn't mine. There's a bigger issue here than "those kids will never learn things the hard way".

A bit of design advice:

- Remove your logo from the header. Your users already pressed the icon on their homescreen to launch your app - they're not confused about what app they're looking at.

- Settle for fewer textures. You have two distinct wood textures that clash, and paper scrolls on top of that. You can distinguish yourself without resorting to a custom background for everything. All the texture obscures the things users can interact with (the refresh button, the scrolls, etc).

- Make the text bigger/make the contrast stronger. Take a look at any app you read a lot in - the font is generally significantly bigger, and on a more distinct background. You're trying to make it look "old" - try old parchment. That's a much more reasonable than a wood floor for reading text.

Watching him set the color for every chunk of an item was really painful. It looked like 1) not a simple or intuitive action and 2) really repetitive and boring.

I imagine it's a case of being slightly blind to one's own features. There's not a single case in the video where sets multiple colors for an item, so it seems like an oversight, probably due to the underlying implementation. Definitely a problem worth solving.

> If only it were as easy as `gem install pg`.

It is with MacRuby, but that's a whole different set of problems :)

Part of the iPad's experience, and part of its success, is that it shares a common language with the iPhone. Removing the home button removes part of the easy transition from one device to the other. If an iPhone owner is thinking of buying a home-button-less iPad, they'll launch an app, and then stare in confusion trying to figure out how to leave it again. Eventually someone will come and explain to them that if you pinch your fingers this certain way, it will take you back to the home screen. And the experience is lessened.

I love the system Apple is building. The gestures built into iOS 5 make it faster and easier for me to use everyday. But gestures are like keyboard shortcuts - they require instruction and they're not discoverable. I think having a so-called "Panic" button exist on the device is important for the way it functions for consumers (not to mention integral to Siri's interface if that makes its way to the iPad). Will it be a physical button? Maybe, maybe not. Removing the only physical button on the device requires a more fundamental change than "three gestures replace all you need the home button for" though.

The iPad presents a unique problem though: you can use the iPad in any orientation. For example, when using it in landscape mode, the home button can be on either the far left or right: it's a huge moving target, and with a screen the size of an iPad, it's often outside your peripheral vision (unlike the iPhone).

What if the home button moves depending on screen orientation? i.e. the home button is always at the center of the bottom-most bezel edge? It's not a particularly usable solution without the best capacitive button ever made, but it's interesting to think about.

If Apple is getting rid of the Home button, there's a lot of complex interaction to account for: http://www.codinghorror.com/.a/6a0120a85dcdae970b0168e681447...

Color me doubtful, though I'd love to be proven wrong. Lots of devices already do a good job with gesture-only interaction, but it requires redefining large chunks of the iOS vocabulary.

Sorry, not "ninja". It's the first one listed under "Text" here: http://www.apple.com/macosx/whats-new/features.html#text

You can disable it from the terminal: http://lifehacker.com/5826055/make-your-keyboard-keys-repeat...

Don't forget all the API changes that present themselves with each new major version. For example, Notifications, GameCenter and Twitter are all new core libraries on the Mac that are accessible to developers.

Given historical trends, the stock will probably take a dip when the iPad 3 fails to meet unsubstantiated expectations.

Try SCSS instead? It provides much better errors for debugging (by virtue of not being javascript-based).

"when it goes wrong, which it does regularly" requires more substance though; LESS or SCSS have never presented a real problem for designers or developers I've worked with. These are valuable tools that address a deficiency when crafting CSS, and should not be discredited so quickly.

Pittsburgh, PA - Bearded (http://bearded.com)

Bearded is a web design and development agency. We’re a small group of web experts focused on inter-disciplinary collaboration as a means to create great websites and applications. Because we’re a small team working on complex projects, our duties frequently overlap, and the ability to work well with others is essential.

Bearded is looking for an experienced Interaction Designer / Front-end Developer / UX Advocate to help us build websites, web applications, and native OSX and iOS applications. Throughout the project process you’ll be collaborating with the other members of Bearded, designers and developers alike. The problems we tackle are often unique and complicated, and require a diverse array of skills and talents working in concert.

Check out http://blog.bearded.com/post/16770645907/you-should-work-at-... for full details.

Rather than A/B test the conversion rates of liking before-or-after, think really hard about what you want to convey. What does a like give you? Is it worth alienating potential users?

You don't need an A/B test to tell you that "If you enjoyed our service, please Like us on Facebook." is a friendlier, more positive request. People have already tweeted about it more than they liked it on Facebook without additional prodding. Let the site stand on its own merits, rather than trying to force promotion through potentially sleazy methods.

"Click the "Like" button to get your tricked out Facebook photos!"

Nope. Closed the window, never going back. If I like your service, I'll tell my friends about it. I won't promote it just to try it out though.

(Yes, I saw the "Already liked us?" button. It doesn't negate the intent to spam people's timelines.)

I can't disagree more strongly. Neither of those apps is successful because they look good. "Good looks" implies an exceptional attention to detail, a deep understanding of the medium, and a solid experience.

More often than not, a beautifully designed piece of software will be easy to use, intuitive, and full of surprises. It makes me want to install it because I _know_ that I'm in for a treat. And when I launch it, my suspicions are confirmed with an app that works exactly as expected without hassle or surprise. Good design is a side-effect of lovingly crafted code and a well-thought out process.

Mozilla - that's a perfect example!

Apple and DRM is interesting. They're pretty expressly against it across rich media content. Their video services are crippled with such awful restrictions due to studio pressure. iOS appears DRM heavy to discourage the unrestricted sideloading of apps, which comes with its own set of pitfalls and dangers for the end user (which, as a commenter points out above, fits within their user-focused view of systems).

Not that their methods are correct; moreso I think that they've created an interesting ecosystem where DRM is non-invasive to the point of being invisible. Really, it's always reminded me strongly of Steam.

Not to troll, but who's on the light side?

Well, had they gone out of business, all of those jobs would have evaporated. It's not a free pass - it's an organizational restructuring. No business would be crucified for killing an unprofitable division; this happened to be an interesting circumstance where said division was an external vendor. Is it a good business decision to EOL an extremely unprofitable (and potentially game-ending) product line, and refocus on your core business? Yes. For every company ever.