If you find meaning from digging into low level libraries, that's great. Most people would think of meaning as having shared values with the business you're working for and it's end users / customers. Prioritize finding end-users who you genuinely care for and whose lives you want to improve is one way to find meaning.
There are actually two products: XControls.org, which augments IBM Domino XPages and also XComponents.org for an Angular.js environment.
This is one of those open source tools that I'd love to see mature into a commercial offering: emailing request tickets, getting bugs fixed, having access to frequent release candidates, etc. I emailed them awhile back asking for commercial license and inquiring about any support they could offer. They're open to the idea, but seem very new to the game.
Begin with a problem then start with the thing that your users will see and work your way down the stack. New students enjoy the immediate gratification from changing a color, moving things around on the browser, or animating a great looking turtle. I recommending having a problem to work within as it provides constraints and a set of mini goals. "I need to take user input" then becomes "I need to process user input" then becomes "I need to put this user input somewhere" and once your friend visits each part of the stack, he can decide where he wants to spend time.
I didn't answer the "fun" part because it's not so great a leading indicator of career direction. Both sides have significant depth and breadth in terms of technical challenges and skill.
This isn't accurate at all. 1) AngularJS was not built by Java developers at Google. Further, it's not clear if the original authors were Java developers. 2) JSF was built by the guy who created Struts, which he did to because he was unhappy with how Struts worked. 3) I wouldn't describe JSF as a Java/XML framework, it's intended to be a component framework.
If I'm not mistaken, access to these videos previously required an account from a GV-funded company. It looks like they've opened up content to everyone. Very cool.
Depending on Google Spreadsheet for uptime monitoring is nothing more than just a fun hack. I'm surprised that some people here are taking it so seriously. If you're using a script like this, then I hope it's just to keep those single dynos from falling asleep :)
It's also subject to Google Docs availability, my script sometimes fails to run with only a "We're sorry, a server error occurred. Please wait a bit and try again." email notification.
I agree. At first glance there's a lot of shorthand (@, =, ^, ?, &) but that knowledge comes with time. I experienced a lot of confusion with the compile() and link() functions that I feel could have been prevented with better docs. Until that's done, I recommend the path I took: lots of experimenting and watching John Lindquist's videos over on egghead.io.
The startup scene is definitely growing in AZ. There are plenty of interesting people doing interesting things. The low cost of living, increasing number of awesome meetups, and growing co-working community is a pretty good sign of things to come. I've met passionate entrepreneurs at almost every corner of the state. Just off the top of my head--Flagstaff has NACET; Tucson is leading the open data movement; Chandler has Gangplank; Phoenix has CO+HOOT & SeedSpot; Mesa has a wonderful Hackerspace; and Marana was recently elected a top digital city in 2012.
That said, there's room for improvement. There aren't a lot of people with experience investing in hi-tech (lots hi-tech military stuff, but not the hi-tech that HN normally discusses); as a community, we don't have really good marketing muscle; there are few veterans willing to recycle capital; and not a lot of foreign direct investment because people have this impression that folks from AZ are crazy.
I love that place though. You can live in a goddamn mansion for the prices you pay in SF.
Want to add two other reasons we're horrible at making estimates.
1. Expectations.
2. No widely accepted language for writing requirements.
Re: 1. Expectations are just hard to manage. Even when you do get "So the site's pretty simple" - the set of features in their brain is totally different from the set of features in your brain. Alas, it'll take more than "all it needs to do is X, Y, Z" to fix this process.
Re: 2. Is there a professional software consulting company that has solved this problem? I say there isn't. I also say that with the advent of Agile/Lean Startup methodologies, it'll probably never happen - "No, we don't write reqs, we have stories you need to approve." uh huh, okay. For writing requirements, I got really damn fond of Cucumber, but then the lean-ux took off, and that shifted everybody's priorities.
Bottom line, until there's a widely accepted way to communicate design and functionality, making bad estimates will always be easy to do
(1) Cloned bootstrap into the Rails.root/lib/assets directory, setup config.assets.path, added the require lines to my css and js files.
Alternatively I could have done:
(2) Used one of the gems mentioned in the comments, added the require lines to my css and js files.
In 2.0, there's some manual work involved to get the js pointing to the correct image path, but assuming you've made it that far, those changes are pretty simple to automatically regex.
IMO, the biggest difference is the way you go about styling markup. In (1), markup is modified intrusively. The example from the OP can be tolerated. But now imagine if all your divs had a .row or .spanxx classes attached. If that's unacceptable for you, I'd find a gem that you can work with.
I was tracking 2.0-wip for a couple of months and it wasn't easy to stay up to date with all the changes. Hopefully it's getting easier for gem authors to track and update