Your statement is true about the "feel" players, but even those players will perform EV analysis away from the table because by estimating percentages of certain tendencies you can figure out what the right play is in tricky situations, and over the long run that ends up saving more money than anything else
True, the way cards come out is chance in a single instance of a hand, but in the long run, over thousands, maybe millions of hands, the cards that you expect to come out will do so more often, and the skillful players will win more often (as opposed to the occasional bad beat).
If you are talking about professional basketball then of course there is luck.. at such a high level a few points, basically a basket, can make the difference between a championship and a lost series, but again, we see the best teams (for the most part) every year in the playoffs repeatedly. The same can be said for rec basketball - the closer the skill levels are of the players to each other, the more luck may play a factor.
I'm really glad someone took the time to do this, and came with quite a wholesome set of resources in the end. For someone who has moderate web dev experience such as myself, I think it's also definitely useful for review as well as the aspects of web dev you may be less/not at all familiar with.
looks like a great guide.. i was working through the original "how to learn angularJS" tutorial, but it got dry through some parts because it was too much material at once without too much of the application behind it in the big picture. I think this tutorial will definitely help with that, good looks!
I think this is correct for personal projects, but when working with teams it's better to create dev branches especially for major feature/functionality additions. I personally try to stick with separate branches and then merge just to uphold that practice, as well as being able to revert/find your mess-ups quicker.
Feature branches in git most frequently only live on the developers machine, often for only a few hours,(unlike feature branches in centralized version control systems, which are almost always long-lived) so there is no harm in not branching if you're only working on something thing . If it is a feature that multiple people need to work on, or needs to be worked on for more than a few hours, then a separate feature branch is of course the correct thing to do.
Branches in git are literally just pointers to commits (write a sha1 object to any file under refs/heads to see what I mean) so they don't really buy you much if you're not frequently switching between locations in the DAG, but can be created retroactively with zero hassle if you do find yourself needing them.
Basically, what you do with your private DAG doesn't matter at all, what is important is that you only publish things that are sensible.
I personally like apple's recent approach to the scrollbar. Hiding it when not in use minimizes distraction. It's very easy to tell how long a single content page article is without needing the scrollbar to persist on the window.
My one issue with the latest Apple scrollbar is that I've yet to figure out a convenient way to scroll horizontally. The horizontal scrollbar is almost always hidden, I can't use my mouse wheel to bring it up, and using arrow keys doesn't always work either.
If anyone has a suggestion, shoot. I went so far as looking for a hotkey for toggling scrollbar display (which I still think would be a good idea), but couldn't find anything. For the record, I'm using Synergy to control mouse/keyboard from a Ubuntu box with a MBP slave machine.
Even worse is trying to click on a file or folder that is last in the window in 'file list' view. You have to wait for the horizontal scrollbar to disappear in order to interact with the last item.
