Skip to content

Instantly share code, notes, and snippets.

View rodigu's full-sized avatar
:electron:
☝️🤓

Rodrigo Morais rodigu

:electron:
☝️🤓
View GitHub Profile
@heyalexej
heyalexej / pytz-time-zones.py
Created November 16, 2016 09:14
list of pytz time zones
>>> import pytz
>>>
>>> for tz in pytz.all_timezones:
... print tz
...
...
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
@mattlewissf
mattlewissf / add-p.md
Last active April 11, 2025 22:02
Lightning Talk: Git add -p

git add -p is your friend

git add -p is basically "git add partial (or patch)"

Patch mode allows you to stage parts of a changed file, instead of the entire file. This allows you to make concise, well-crafted commits that make for an easier to read history. This feature can improve the quality of the commits. It also makes it easy to remove parts of the changes in a file that were only there for debugging purposes - prior to the commit without having to go back to the editor.

It allows you to see the changes (delta) to the code that you are trying to add, and lets you add them (or not) separately from each other using an interactive prompt. Here's how to use it:

from the command line, either use

  • git add -p
@zsup
zsup / ddd.md
Last active May 29, 2025 23:22
Documentation-Driven Development (DDD)

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

  • Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
  • Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
  • Once documentation has been written, development should commence, and test-driven development is preferred.
  • Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
  • When a feature is being modified, it should be modified documentation-first.
  • When documentation is modified, so should be the tests.
@jtdp
jtdp / gist:5443297
Last active April 2, 2025 22:15
See changes before pulling from remote git repository
# fetch the changes from the remote
git fetch origin
# show commit logs of changes
git log master..origin/master
# show diffs of changes
git diff master..origin/master
# apply the changes by merge..