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.
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.
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".
- 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.
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.
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.