TL;DR Uses a browser plugin and browser is refreshed every time a source code file is saved - no server restart, build or even browser refresh required. Less clicks = better.
1,925 karma · joined June 7, 2010
- The name - as already has been raised by others implies that you have done something wrong.
- Adding to the file requires a degree of confidence and maturity among your team and a level of trust among the group.
- The existence of such a file might reduce effort on the part of some. After all if "shameful" hacks are OK, why bother with real solutions?
- Internal refactoring as an separate independent initiative is sometimes difficult to justify from a financial or political perspective.
In a group with self-aware, well educated, and motivated developers, these concerns might be rather small. But in many larger organizations (with practices that sometimes make Dilbert comics appear tame), this would not work as well for these and other related reasons.
Don't get me wrong, I really like the idea. And since css code is relatively "free" to be included in an arbitrary file, calling out questionable code in this way does seem to have its merits. Perhaps its the use of the term shame that tips me off, but that is a concept that is understood very differently by different people and different cultures. So - like many suggestions - it might work well depending on your group, but is unlikely to be adopted as a universal best practice.
Working on multiple projects makes you feel like you don't have time to waste, and so there is a tendency to make better use of time worked on each. There is also a need to properly prioritize across projects - which might be a considered a way of sneaking "focus" back into the picture after all.
Disclaimer: I liked it enough to buy a personal license :), but am not affiliated with the folks who make and sell it.
$('.donut-arrow').attr('style','-webkit-transform: rotate(85deg)')
1) Newly added elements will not respond unless events are bound to them. One solution (thinking in jQuery here) is to bind events higher up the DOM.
2) Each line in code may not simply execute in sequence. For example, asynchronous ajax calls require subsequent calls to be nested in callbacks.
If you have to deal with directed graphs, iGraph http://igraph.sourceforge.net/.
Related Blog Posts
http://www.r-chart.com/2010/06/stock-analysis-using-r.html
http://www.r-chart.com/2010/06/analyze-twitter-data-using-r....
1) Check out http://www.r-bloggers.com/. The site gives you a good sense of the state of R and Tal (who runs the site) has done a great job of promoting R and encouraging the community.
2) Pick one graphics package and stick with it. The standard functions are sufficient but ggplot2 has a more finished appearance.
3) Review available libraries. If you want to do something, someone else likely already has and has posted a package to CRAN.
4) One way for SQL developers to limit the need of learning the idiosyncrasies of the language is to use the sqldf package to manipulate data frames and use ggplot2 (which generally takes data frames as arguments) to display charts.
The twenties are for launching, while the thirties are for building what you launched.
The main point is to recognize the state of your brain at a given age and its resulting effects:
The trick is simply to take advantage of each power in the season it is given
That is applicable regardless of chronological age.
AngularJS is not new to the mainstream JavaScript community - but it is to many others who can derive a lot of benefit from it. Good see to a tutorial to get such folks up and running quickly with it.
BTW - if you prefer text to video, here is a related post from the authors blog:
http://jphoward.wordpress.com/2013/01/04/end-to-end-web-app-...
Source at Google Code: http://stab-language.googlecode.com/svn/trunk/.
Seems to be available on Github now as well: https://github.com/eropple.
Zed does acknowledge as much but this is worth pointing out. For some reason contextual intent and "intended audience" are missed by programmers (who are typically stereotyped for giving answers that are a technical depth irrelevant to the recipients).
With that in mind, I think that describing the intended audience and context (as you and others in the comments have done) is a more valuable exercise. It makes K&R (or other book) accessible and applicable to a new generation. Such posts won't normally get much intention - they lack a certain rebellious and inflammatory flair we know and love so well...
- JavaScript looks a bit like (Java/Ruby/other language)
- JavaScript does not work like (said language)
- JavaScript sucks
Granted, I appreciate folks pointing out the "bad parts" of the language and the strange gotchas. And JavaScript has more than its share of bad parts. But it also requires a change in mindset. At minimum, expect
- a priority of first-class functions,
- Prototypal rather than classical inheritance,
- time spent learning JavaScript syntax itself instead of constructs from other languages (which often will work, but not in the way expected).
Books that have given me a renewed appreciation are Douglas Crockford's book (JavaScript the Good Parts) and John Resig's "Secrets of the JavaScript Ninja."