These are decent tips, but each generally just triggers GPU rendering, in most cases unless you have a specific reason to use the transform only one of those rules will suffice.
This simplifies the actual problem though. Blanketing GPU 'hacks' is rarely the best solution where mobile is concerned and you should really think a lot harder about where and when you want to ask the GPU to do some work. Even when blanketing these rules over your elements you can find that GPU rendering is turned on and off which will result in flicker.
Until you really get a good idea on how animating rules work with your content it is really a case of experimenting with how to run your transforms.
Decent enough tips but better would be to make sure that devs understand exactly how these rules affect the browser and the rendering.
Yeah I do this as I have a number of places to ssh into. Great tip, I'd be surprised if most people werent doing this.
Yeah gulp is great. I use it in almost all of my newer projects and am slowly changing some pretty weighty grunt build processes to use gulp. However, this isnt always easy as gulp requires a fundamental shift in how you do some things and this, I think, is what puts people off.
Embracing streaming for data transformations is generally a fantastic idea and gulp is great at what it does, adding concurrency and its pretty elegant. It still has a few issues to iron out but I'd hope gulp is here to stay as its a fantastic way to build JS projects.
I'm a magic mouser so had no idea about it this but the principle can be generalised to any 'standard' functionality. Even if 'you' dont do this thing often, dont slight those who do. Standards exist for a reason and you better have a good reason if you're going to break them.
Yeah reinventing the wheel for the sake of it isnt a great idea but doing so for learning purposes sounds like a great idea. I'd advocate this approach for a number of different things—write your own blogging software, write your message service, write your own framework, write your own language and parser, write your own file streaming utility, write your own DOM manipulator, write your own template parser etc etc.
Do these things (and more) to learn, other solutions exist for you to use but doing your own one first will help understand the problems that these solutions aim to solve. This will help you not only pick which solution is best for you but which solution best solves the problems you're tackling. Then hack into them and make them work exactly how you need.
Although its nearly mentioned in an earlier comment its worth noting that :not won't work IE <9 so if extensive compatibility is a concern that the + trick above is your man (if you really want to remove a few lines of CSS).
Surely it's only a case of no SASS... yet. If they don't do it themselves someone will (if its popular).
Yeah, it's ace and forever-monitor means you have all that goodness programmatically too
Can't agree more with the comments about a prospects Github account. As mentioned, it speaks volumes about the coding personality and skills of the interviewee, which leaves the interview clear to just decide on whether the person's personality is going to fit with the company/team. Critically, this doesn't waste time of the interviewer/company or the applicant.
Is this Mountain Lion only? Probably worth mentioning that on 10.7.x (Lion) pmset -g will not show standbydelay.
What if I spend most time with family online? (I dont, but many do), what if my family all live 1000 miles away and online is the best place?
What if most of my friends don't do the whole online thing? Will I still feel that social media is overtaking me? I don't.
Interesting post, well made, but it's scare mongering about the 'dangers' of the internet when there is actually no danger. The general 'people' will continue to do largely as they have done for a very long time, just because the technologies of interaction have changed doesn't mean the intrinsic value of the interaction has changed.
The 'impersonal' or 'anonymous' message will become a relic of the past as technology continues to evolve and become more and more integrated with our concept of self anyway so it's moot and transient to worry too much about it.
Although, having said all that, I'd concur that face to face family/friends time should still be the most 'important' interaction we hold.
process.env.HOME || process.env.HOMEPATH || process.env.USERPROFILE should cover all bases
Some good stuff, I'd definitely recommend organising code by feature early on, partly for your own sanity but partly because on-boarding anyone else on the project will be easier and they'll get an overview of the whole project structure just by looking at files/folders rather than rooting through files/folders.
Yes, I use moment.js too to make things a little easier
Why would you attach routes to the window?
Presumably they dont change during the life-cycle of the session? Angular can be a little touchy about globals but its generally not a great idea to be attaching things to the window when it isnt necessary anyway.
In your example you could attach your routes straight to MyApp or add it as part of a config file and then attach it in the config
Yeah there are a couple of $interval implementations kicking around, with various degrees of success.
Hoepfully it'll be standard soon.
Fair enough. Nice shell customisation..
What’s wrong with cmd-w for quitting the tab or cmd-q for killing the app?
Ran this through jsperf to get a quick comparison op-wise http://jsperf.com/anonymous-vs-named-settimeout-in-a-loop, anonymous is marginally quicker (although it might of been worth upping the number of loops) but the anonymous also has the edge on keeping the namespace tidy and, for me at least, is a slightly more elegant solution.
It's keeping the namespace tidy that gives it my nod.
You can never attribute for the level of skill of the next person to read your code either, that means comment (where sensible) for a fairly low level. This will allow junior devs to learn from/read your code and allow high-level devs to skim-read your comments until you throw in something complex, whereby they read your comments and understand what you've done (be it right or wrong).
Readable code means more easily extensible code, for you in 3 months time or for another dev, this is a good thing. Compared to proper documentation (which is also good) readable code is easy so there are simply no excuses, even if you are pre-disposed to writing over-complex spaghetti-code, a good piece of commenting will do wonders for the next chap.
Comments are easily removed during the build process anyway but needn't be a chore, like writing tests, writing comments first and then implementing can help even the most advanced to write good code.
Yes, I agree, never had any problem with integrating MVC into games in any language and there's absolutely no probs in doing so for javascript as well.
I also agree with the comments that making your code readable is important. A maintable, debuggable and extensible codebase is a joy to work with, one that does not meet those criteria is a pain.
It would depend on what sort of game it was though as to how useful implementing MVC would be but it would have relevance to all and probably in most cases produce a better codebase.
Yep the -g installs globally, you can run it from where you like
Achievements
53 Karma
1,002 Total ProTip Views
Altruist
Kona
Charity
Honey Badger
Are you suggesting this as a good thing?
Do you prefer it over feature detection?
I do use something similar to fix edge cases but providing code like this should come with a caveat that there are better ways to solve the actual problem.