Most people aren't writing HTTP requests by hand in a text editor.
3,882 karma · joined March 12, 2011
website: thomasboyt.com
In ST3, no such problems.
My worry is that flat design will lead to less information density (because of the decreased emphasis on visual hierarchy and separation through 3D effects) and lead to a downgrade in functionality for some apps. Honestly, I wouldn't be bothered if Tweetbot stayed the same.
* (not that algorithm knowledge isn't practical, but for a lot of smaller, "web-interface-around-a-database" startups, they're not nearly as important as being comfortable around a full web stack)
I'll admit that my situation isn't universal - luckily, I could get my foot in the door with many startups by being in the last batch of Hacker School - but if you, like me, hate academia and want to get to work, don't let your age stop you. Sure, there's companies that care about your schooling - the Googles, Twitters, Facebooks, and Palantirs of the world - but there are so many more that just want great hackers with awesome GitHub profiles and real-world chops.
(and, of course, make sure to never stop learning on your own time! You will, inevitably, have gaps in your knowledge you missed from school, but between Coursera, the availability of free textbooks and lectures, and other resources, it's not hard to remedy that on your own)
Lots of cool stuff in this release, but the best of it is Alex Matchneer's excellent "Router facelift" patch, which standardizes and promise-ifies the router (while not changing the public API, unlike the last router update). He wrote a guide to it here: https://gist.github.com/machty/5723945
Really useful when you have lots of keybindings.
Any idea when GitHub Pages will start using 1.0 (or are they using it already?). Really want to start using that gist tag ASAP (copy-pasting the <script> embeds is a bit of a pain).
I mean, I'm in Hacker School this batch (which is sadly ending this week) and I live in a hostel in Bed-Stuy for $650/mo. You don't have to be rich. Certainly way cheaper than college tuition for me.
Exactly how are those techniques not tools of their own? A binary tree is a tool just like a language or a framework is. A quick sort or a merge sort is just another tool - hell, if I'm using a modern language, I can quite easily get any number of sorts in libraries. And what do I gain from learning the implementation details? Divide and conquer algorithms and recursion are wonderful, but simply saying "learn QuickSort" is emphasizing the wrong things.
I'm biased. I'm 19 and never took a formal CS course. I've self-taught myself some of these concepts - not all (bit twiddling is still a mystery to me). But the best programming learning happens organically. I learned how trees worked not out of a book, but because I needed to implement a parent-child relationship in a note-taking app I built. I learned recursion by learning how to do elegant functional programming in JavaScript to simplify my code.
This is how learning happens. You code. You realize your code sucks. You learn to code better. You realize you don't know how to implement something. You learn all you can about it, then you implement it.
Learn concepts because they're practical, not because they're on a list of Shit You Need to Know For Your Whiteboarding Interview. Every single one of the concepts on that list has practical applications, but there's no reason to memorize them and know them by heart unless you plan to use all of them tomorrow.
Otherwise, you're just falling into the same trap you do using a site like CodeSchool: missing the bigger picture of hacking. You're here to build. Learn what you need to do that.
Anyways, as for the way you're handling relationships:
The RESTAdapter works like it does because it expects hasMany<->belongsTo relationships. In that relationship:
- It can load the child record from an array of IDs on the parent.
- When a child record is updated, it is saved back to the server without including the parent.
- When a child record is added, it only saves itself back to the server. The server is expected to handle adding that record to the parent resource.
- Similarly, when a child record is deleted, it is saved back to the server and the server should remove it from the parent resource.
Essentially, the client shouldn't need to save the list of children back to the server.
The downside of this is that this doesn't actually work in a hasMany<->hasMany relationship, because a record in that relationship does need to send back the list of resources - it's the same as the way a belongsTo record will include its parent.
Regardless, there's no obvious harm in overriding RESTAdapter to do this, and it shouldn't impact the way that a regular hasMany<->belongsTo relationship is handled. Just make sure that the client-side records always have a current representation of their relationships, or you might end up saving back incorrect versions of the records.
I know that the documentation right now is really lacking, but it's hard to tell what needs improvement when you're not the one trying to learn it :)
I actually really like Spider-Man for that reason. Yes, he had the luck to be bitten by a radioactive spider, but he also built a ton of his gadgets himself (in the comics, for example, the web shooter is all him) and took on a ton of responsibility at a very young age.
Unfortunately, that seems to lead to a lot of acrimony between them. I wonder if a big part of it is that each side is convinced there won't be space for both in the future, and that a clear winner has to be declared - which I don't think is true at all. This town is certainly big enough for the both of them :)
As for drama within the Ember community itself, that's a little more complex. I think a big part of it is that Ember seems to have a lower barrier to entry than Angular at first glance, but certainly has its own catches and hang-ups, and running into those when you thought you had found a holy grail can be extremely frustrating.
<a href="#" id="show-help-link">Show Help</a>
<script src="text/javascript">
$("#show-help-link").click(function() { showHelp(); } );
</script>
<a href="#" ng-click="showHelp()">Show Help</a>
(do agree with other comments that per-dev pricing is a bad model, though)
What I don't see - and again, I have not dived very deeply into the router; I'm going off the documentation here - is how to keep views during the transition. In my app, the router has to re-render all views when changing between routes. This isn't a huge deal, as it's a very lightweight application. Still, Backbone offers much more flexibility when it comes to views.
This is actually a really important point. This is exactly how Ember's router works, as far as I can see from the documentation - when you transition, you lose all prior state. It's essentially trying to emulate traditional routing, which defeats the point.
- Loading splash is very nice.
- Grid view looks good. Would like to see your take on the "list view," which I generally prefer.
- The chat seems to waste a lot of space, especially with the top bar. The current Steam interface is much more information-dense, which as someone with a 1280x800 screen, I very much enjoy :)
I'd love to see your take on a redesigned storefront and community sections, too. I don't really have any issue with how Steam looks now (just how it functions - the OSX app was broken for so long in so many ways!), but I like the visual refresh you've made!