JustDevZero

#!/bin/bash
# based on http://www.snip2code.com/Snippet/165926/Check-for-ipdb-breakpoints-git-hook

pdb_check=$(git diff-index -U --color=always --cached -G '[ ;]i?pdb' HEAD)
if [ ${#pdb_check} -gt 0 ]
then
        echo "COMMIT REJECTED: commit contains code with break points in python. Please remove before commiting."
        echo $pdb_check
        exit 1
else

stettix

Things I believe

This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.

Agree? Disagree? Feel free to let me know at @JanStette. See also my blog at www.janvsmachine.net.

Fundamentals

Keep it simple, stupid. You ain't gonna need it.

twidi

"""
Sometimes in your Django model you want to raise a ``ValidationError`` in the ``save`` method, for
some reason.
This exception is not managed by Django Rest Framework because it occurs after its validation 
process. So at the end, you'll have a 500.
Correcting this is as simple as overriding the exception handler, by converting the Django
``ValidationError`` to a DRF one.
"""

from django.core.exceptions import ValidationError as DjangoValidationError

peterhurford

Using py.test is great and the support for test fixtures is pretty awesome. However, in order to share your fixtures across your entire module, py.test suggests you define all your fixtures within one single conftest.py file. This is impractical if you have a large quantity of fixtures -- for better organization and readibility, you would much rather define your fixtures across multiple, well-named files. But how do you do that? ...No one on the internet seemed to know.

Turns out, however, you can define fixtures in individual files like this:

tests/fixtures/add.py

import pytest

@pytest.fixture

alces

• using Ansible command line:

ansible-playbook --connection=local 127.0.0.1 playbook.yml

• using inventory:

127.0.0.1 ansible_connection=local

gtallen1187

"A little bit of slope makes up for a lot of y-intercept"

01/13/2012. From a lecture by Professor John Ousterhout at Stanford, class CS140

Here's today's thought for the weekend. A little bit of slope makes up for a lot of Y-intercept.

[Laughter]

isaacs

# Hello, and welcome to makefile basics.
#
# You will learn why `make` is so great, and why, despite its "weird" syntax,
# it is actually a highly expressive, efficient, and powerful way to build
# programs.
#
# Once you're done here, go to
# http://www.gnu.org/software/make/manual/make.html
# to learn SOOOO much more.

myusuf3

To remove a submodule you need to:

• Delete the relevant section from the .gitmodules file.
• Stage the .gitmodules changes git add .gitmodules
• Delete the relevant section from .git/config.
• Run git rm --cached path_to_submodule (no trailing slash).
• Run rm -rf .git/modules/path_to_submodule (no trailing slash).
• Commit git commit -m "Removed submodule "
• Delete the now untracked submodule files rm -rf path_to_submodule

OnesimusUnbound

[T]he difference between a bad programmer and a 
good one is whether he considers his code or his 
data structures more important. Bad programmers 
worry about the code. Good programmers worry about 
data structures and their relationships. 
-- Linus Torvalds
~~~
Clarity and brevity sometimes are at odds. 
When they are, I choose clarity. 
-- Jacob Kaplan-Moss

jboner

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD