Sublime Text 2 ships with a CLI called subl (why not "sublime", go figure). This utility is hidden in the following folder (assuming you installed Sublime in /Applications like normal folk. If this following line opens Sublime Text for you, then bingo, you're ready.
open /Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl
You can find more (official) details about subl here: http://www.sublimetext.com/docs/2/osx_command_line.html
Sublime Text 2 ships with a CLI called subl (why not "sublime", go figure). This utility is hidden in the following folder (assuming you installed Sublime in /Applications like normal folk. If this following line opens Sublime Text for you, then bingo, you're ready.
open /Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl
You can find more (official) details about subl here: http://www.sublimetext.com/docs/2/osx_command_line.html
| { | |
| "AL": "Alabama", | |
| "AK": "Alaska", | |
| "AS": "American Samoa", | |
| "AZ": "Arizona", | |
| "AR": "Arkansas", | |
| "CA": "California", | |
| "CO": "Colorado", | |
| "CT": "Connecticut", | |
| "DE": "Delaware", |
Custom recipe to get OS X 10.9 Mavericks running from scratch, setup applications and developer environment. I use this gist to keep track of the important software and steps required to have a functioning system after a semi-annual fresh install.
The software selected is software that is "tried and true" --- software I need after any fresh install. I often install other software not listed here, but is handled in a case-by-case basis.
| #!/bin/sh | |
| ### | |
| # SOME COMMANDS WILL NOT WORK ON macOS (Sierra or newer) | |
| # For Sierra or newer, see https://github.com/mathiasbynens/dotfiles/blob/master/.macos | |
| ### | |
| # Alot of these configs have been taken from the various places | |
| # on the web, most from here | |
| # https://github.com/mathiasbynens/dotfiles/blob/5b3c8418ed42d93af2e647dc9d122f25cc034871/.osx |
If you're writing web applications with Ruby there comes a time when you might need something a lot simpler, or even faster, than Ruby on Rails or the Sinatra micro-framework. Enter Rack.
Rack describes itself as follows:
Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.
Before Rack came along Ruby web frameworks all implemented their own interfaces, which made it incredibly difficult to write web servers for them, or to share code between two different frameworks. Now almost all Ruby web frameworks implement Rack, including Rails and Sinatra, meaning that these applications can now behave in a similar fashion to one another.
At it's core Rack provides a great set of tools to allow you to build the most simple web application or interface you can. Rack applications can be written in a single line of code. But we're getting ahead of ourselves a bit.
| class Graph: | |
| def __init__(self): | |
| self.nodes = set() | |
| self.edges = defaultdict(list) | |
| self.distances = {} | |
| def add_node(self, value): | |
| self.nodes.add(value) | |
| def add_edge(self, from_node, to_node, distance): |
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.