It doesn't seem you can lose data even when you might otherwise expect to ;) I setup a small replica set using mongod --fork --logpath a.log --smallfiles --oplogSize 50 --port 27001 --dbpath data/z1 --replSet z mongod --fork --logpath b.log --smallfiles --oplogSize 50 --port 27002 --dbpath data/z2 --replSet z mongod --fork --logpath c.log --smallfiles --oplogSize 50 --port 27003 --dbpath data/z3 --replSet z And initalized it: > rs.initiate( { _id:'z', members:[ { _id:1, host:'localhost:27001' }, { _id:2, host:'localhost:27002' }, { _id:3, host:'localhost:27003' } ] } ); Then I killed all three processes: kill -9 25542 25496 25483 Next I brought one of them back up mongod --fork --logpath c.log --smallfiles --oplogSize 50 --port 27003 --dbpath data/z3 and inserted a doc > db.foo.insert({a:1}) Then I killed that process kill -9 25885 and brought the replica set back online using mongod --for

alias ls='ls -ah --color=always' alias ll='ls -lavh --color=always' alias cp='cp -i' alias vi='/usr/bin/emacs' alias ..='cd ..' alias ...='cd ../..'

If you want to leave Github for whatever reason, you probably want to take all your code with you, and all your history and branches, etc. Here's an example for how I moved my Android Eclipse workspace from Github to my own remote server. First I make a new git repo on my remote server: $ git --bare init ~/git/workspace The --bare option means I'm not going to work on the code in the remote git repo directly. Next I push my current local 'master' to the new repo: $ git checkout master $ git push ssh://me@myserver.com/git/workspace master After that I push my working branch: $ git checkout work $ git push ssh://me@myserver.com/git/workspace work You could repeat this step if you have more branches. I created my local repo using 'clone' so it has an 'origin' remote branch defined. This 'remote' branch is where git fetches and pushes changes. Right now my 'fetch' and 'push' remote origins point to Github: $ git remote -v git@github.com:gdonald/workspace.git

Motivation If your software project doesn't "get users" it will die, bottom line. Launching a software project into production sooner rather than later greatly increases the odds the project will "get users" and ultimately succeed. Situation You've seen it time and again in recent years. You start a new project. You have project specs and a strong desire to include a test suite with your project to prove correctness and efficiency. But along the way your project specs change, you don't launch on time, and you have a gazillion tests to update. Your hopes of actually "getting users" dwiddles daily as you cope with all the code and test code changes. What do you do? Solution Throw out your test suite and launch the project into production. Having users actually use your software provides near 100% code coverage. Having your "test suite" run in production on real data means you do not waste time creating fake data in the form of fixtures or factories. Continuous integration is provided as a side

I had a problem with PostgreSQL pgdump recently. My setval() calls were all set to '1'. I whipped up this quick script to fix things: #!/usr/bin/env python DB_NAME = 'my_db' from subprocess import Popen, PIPE import re exclude = [ 'tablename', 'rows' ] tp = re.compile( '[^a-z_]' ) ts = Popen( [ "/usr/bin/psql", DB_NAME, "-c SELECT tablename FROM pg_tables WHERE tablename NOT LIKE 'pg_%' AND tablename NOT LIKE 'sql_%' ORDER BY tablename" ], stdout=PIPE ).communicate()[ 0 ].split( ' ' ) tables = [] for t in ts: t = tp.sub( '', t ) if len( t ) == 0 or t in exclude: continue tables.append( t ) for t in tables: sql = "SELECT pg_catalog.setval( pg_get_serial_sequence( '%s', 'id' ), ( SELECT MAX( id ) FROM %s ) + 1 );" % ( t, t ) print Popen( [ "/usr/bin/psql", DB_NAME, "-c %s" % sql ], stdout=PIPE ).communicate()[ 0 ]

# basic .muttrc for use with Gmail # Change the following six lines to match your Gmail account details set imap_user = "username@gmail.com" set imap_pass = "" set smtp_url = "smtp://username@smtp.gmail.com:587/" set smtp_pass = "" set from = "username@gmail.com" set realname = "Firstname Lastname" # # # Change the following line to a different editor you prefer. set editor = 'vim + -c "set textwidth=72" -c "set wrap"'

If you're using a flavor of *nix that has an rc.local file, and then you start using Debian GNU/Linux, you might be wondering where your rc.local file is. Quite simply, it's not there. Here's how to add it. Create a new file named /etc/init.d/local like this: #!/bin/sh # put startup stuff here Make the file executable: chmod 755 /etc/init.d/local Add it to startup: update-rc.d local defaults 80 You should be seeing something like this: Adding system startup for /etc/init.d/local ... /etc/rc0.d/K80local -> ../init.d/local /etc/rc1.d/K80local -> ../init.d/local /etc/rc6.d/K80local -> ../init.d/local /etc/rc2.d/S80local -> ../init.d/local /etc/rc3.d/S80local -> ../init.d/local /etc/rc4.d/S80local -> ../init.d/local /etc/rc5.d/S80local -> ../init.d/local

Here's a command to install lots of games on your Debian box: yes | \ for x in `apt-cache search game \ | sort \ | awk 'BEGIN { FS = " - " } { print $1 }'`; do \ apt-get install $x; \ done

   Page Updates
Install and setup snmpd on RedHat Enterprise Linux
Install and setup irssi and oidentd on Debian
ORM::ActiveRecord
Template::HAML
BDD::Behave
   Recent Articles
Install xfce4 on Debian
Console Blackjack in Perl
Selenium::WebDriver::Error::UnknownError
Game of Life in C++ using the SDL2
PigPen (dots and boxes) in C++ using the SDL2
   Tags
active-record (2) android (1) apt (1) awk (2) bash (2) bashrc (1) battleship (1) bdd (1) blackjack (12) book (1) books (1) build (1) c (2) c++ (2) cacti (1) capybara (1) clang (1) clang++ (1) console (5) cpp (2) crm (1) crystal (1) data (1) debian (7) diff (1) elixir (1) fedora (1) firewall (1) freebsd (1) g++ (1) game (4) games (1) gcc (1) gem (1) git (3) github (1) gmail (1) go-lang (3) google-chrome (1) haml (1) infix (1) irssi (1) kernel (3) latin1 (1) life (1) linux (4) lottery (1) meta (1) microsoft (1) moarvm (1) model (1) module (1) mongodb (1) mp3s (1) mutt (1) nautical (1) nqp (1) object (1) oidentd (1) operator (1) orm (2) pairing (1) pair-programming (1) patch (1) perl (1) pigpen (1) postgresql (2) powerball (1) programming (1) psql (1) python (2) python3 (1) raku (14) raspberrypi (1) reactjs (2) readline (1) reversi (1) rhel (1) ruby (1) sdl2 (4) sed (1) selenium (1) selinux (1) snmpd (1) split (1) ssh (1) stack (1) template (1) testing (3) tictactoe (1) trace (1) typescript (2) ubuntu (2) utf8 (1) virus (1) war (1) xargs (1) xfce4 (1) xvfb (1) zef (1)
   Twitter

Copyright © 2005 - 2020

GregDonald.com · Contact

All Rights Reserved