| sayHello2 = (name) -> | |
| text = "Hello #{name}" | |
| sayAlert = -> | |
| alert text | |
| sayAlert() |
| function bash_git_branch | |
| { | |
| git branch 2> /dev/null | grep \* | python -c "print '['+raw_input()[2:]+']'" 2> /dev/null | |
| } | |
| PS1='${debian_chroot:+($debian_chroot)}\W: $(bash_git_branch)\$ ' |
| root = if window? then window else global | |
| root.$ = require("jquery") | |
| root.jQuery = $ |
Right now, I don't think any of us use Sass/Scss, Less, or Stylus to the point where switching back and forth isn't possible. They're all basically the same until you get into the super power user features which, none of us have embraced quite yet.
#Sass/Scss
We obviously know what Sass and Scss are. I think the css-compatible format is pretty nice option even though, ascetically, I prefer sass.
body
background-color:red;
This is already happening. We have devices in the market that already have high pixel density displays besides Apple's Retina screens and we know no one plans on scaling back on this technology. We also know that, all though, the majority of these devices are on mobile phones and tablets, mobile is playing a larger part in the web and also isn't going to start slowing down any time soon.
Will we all just blindly follow Apple's iOS workflow and create multiple assets for multiple resolution targets? some-image.png and some-image@2x.png?
There's definitely more options than this and the web isn't such a simple place where we can just accept apple's native app work flow and expect it to work without any consequences.
##Backend:
##FrontEnd:
Beyond any other definition, Behavior Driven Development/Design ("BDD") is a philosophy.
"BDD" is a set of tools and techniques that exist to support one idea: good software is written to meet the needs of the stakeholders (typically clients).
These stakeholders know their business better than the people designing the software. It is the responsibility of developers to capture the business requirements and translate them into software.
BDD tools facilitate this as a process by letting developers author features first, which capture requirements in a domain-specific language. Code is developed by working on these high-level features, and then on code specifications.
| window.DeviceRedirect = class DeviceRedirect | |
| constructor: (@platforms, @envRegEx, @ignoreList...) -> | |
| init: -> | |
| @currentLocation = window.location.href.toLowerCase() | |
| @isHere = if @currentLocation.match @envRegEx then true else false | |
| ismobile = (/iphone|ipod|android|blackberry|opera mini|opera mobi|windows phone|palm|iemobile/i.test(navigator.userAgent.toLowerCase())) | |
| istablet = (/ipad|tablet/i.test(navigator.userAgent.toLowerCase())) | |
| isdesktop = if ismobile or istablet then false else true |
Why do we need to tell Objective-C what types of pointer variables something is when it's obvious after we alloc it?
NSFetchedResultsController *aFetchedResultsController = [NSFetchedResultsController alloc]Shouldn't it be as simple as
aFetchedResultsController = NSFetchedResultsController alloc
| String::toCSSMatrix3d = -> | |
| webKitCSSMatrix = new WebKitCSSMatrix @ | |
| matrix3d = "matrix3d(#{webKitCSSMatrix.m11},#{webKitCSSMatrix.m12},#{webKitCSSMatrix.m13},#{webKitCSSMatrix.m14},#{webKitCSSMatrix.m21},#{webKitCSSMatrix.m22},#{webKitCSSMatrix.m23},#{webKitCSSMatrix.m24},#{webKitCSSMatrix.m31},#{webKitCSSMatrix.m32},#{webKitCSSMatrix.m33},#{webKitCSSMatrix.m34},#{webKitCSSMatrix.m41},#{webKitCSSMatrix.m42},#{webKitCSSMatrix.m43},#{webKitCSSMatrix.m44})" | |
| matrix3d | |
| console.log "scale3d(2, 2, 0) translate3d(-454px, 0px, 0px) rotate(1deg)".toCSSMatrix3d() |