This gist's comment stream is a collection of webdev apps for OS X. Feel free to add links to apps you like, just make sure you add some context to what it does — either from the creator's website or your own thoughts.
— Erik
| #!/usr/bin/env sh | |
| # Download lists, unpack and filter, write to stdout | |
| curl -s https://www.iblocklist.com/lists.php \ | |
| | sed -n "s/.*value='\(http:.*=bt_.*\)'.*/\1/p" \ | |
| | xargs wget -O - \ | |
| | gunzip \ | |
| | egrep -v '^#' |
Dies ist ein Experiment, das zeigt, wie man ein Modul in einer fremden Sprache in [Node][] laden kann.
Dies ist ein Stück [Forth][]:
: sq ( x -- x² ) dup * ; 3 4 * dup . sq .
Der Programmcode definiert ein neues Wort sq, welches (wie der in runde Klammern eingeschlossene Kommentar erläutert) die oberste auf dem Stack befindliche Zahl quadriert. Danach berechnet es das Produkt von 3 und 4, gibt es aus und quadriert das Ergebnis und gibt auch das aus.
| /* source : http://forums.macrumors.com/showpost.php?p=15332289&postcount=20 | |
| It's easy to fix iStat Pro processes for Mountain Lion | |
| Steps: | |
| 1. Locate your widget, it will be under /Library/Widgets or ~/Library/Widgets | |
| 2. Right click it and select: "Show Package Contents" | |
| 3. Open Wide.js or Tall.js file in some editor (Wide is for horizontal view, Tall for vertical) |
| #!/bin/bash | |
| # From http://tech.serbinn.net/2010/shell-script-to-create-ramdisk-on-mac-os-x/ | |
| # | |
| ARGS=2 | |
| E_BADARGS=99 | |
| if [ $# -ne $ARGS ] # correct number of arguments to the script; | |
| then |
To setup your computer to work with *.test domains, e.g. project.test, awesome.test and so on, without having to add to your hosts file each time.
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
People
:bowtie: |
😄 :smile: |
😆 :laughing: |
|---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j