Here are the URLs for creating a Google Single Sign On. Access Google OAuth via your web server: http://code.google.com/apis/accounts/docs/OAuth2WebServer.html Google Access Tokens: https://accounts.google.com/b/0/IssuedAuthSubTokens Google APIs: http://code.google.com/apis/gdata/docs/directory.html Android OAuth: https://sites.google.com/site/oauthgoog/oauth-practices/mobile-apps-for-complex-login-systems/samplecode#TOC-3.2.-Android Service Connection Example: http://developer.android.com/training/id-auth/authenticate.html#ConnectToService Google OAuth Playground: http://googlecodesamples.com/oauth_playground/ Google Data AuthScopes: http://code.google.com/apis/gdata/faq.html#AuthScopes Google Python Client Library: http://code.google.com/p/google-api-python-client/ Google Oauth2 Login: http://code.google.com/apis/accounts/docs/OAuth2Login.html
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 (
Here's the part where Apple proves iOS isn't ready for "Enterprise" apps: NSString *p=@"/private/var/wireless/Library/CallHistory/call_history.db"; sqlite3 *d; if(sqlite3_open([p UTF8String], &database) == SQLITE_OK) { NSLog(@"call_history present"); } else { NSLog(@"Failed to open database with message '%s'.", sqlite3_errmsg(d)); sqlite3_close(d); }

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 ]

I thought someone else may need a complete working example, all in one chunk of code: <VirtualHost 127.0.0.1:80> ServerName mysite ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/mysite.log combined ErrorDocument 404 / DocumentRoot /mysite Alias /robots.txt /mysite/static/robots.txt Alias /favicon.ico /mysite/static/img/favicon.ico Alias /static/ /mysite/static/ WSGIScriptAlias / /mysite/wsgi.py <Directory /mysite> <Files wsgi.py> Require all granted </Files> </Directory> <Directory /mysite/static> Require all granted </Directory> </VirtualHost>
I recently set out to learn more about git, the new content manager for source code. "New", as in much younger than Subversion, and a hell of a lot younger than CVS! No one I know personally uses git yet, but I see the Ruby on Rails community starting to use it a bit, so I decided I had better get up to speed. I didn't really need the full power of git. I just needed a simple setup, somewhere I could commit code over SSH. The initial steps for such a setup were not exactly simple to learn as a first-time git user. Hints were scattered across many different websites. So I'm documenting everything I've learned here in a blog entry, in case other git n00bs like myself might find it useful. First make a new git repo on your remote host: mkdir -p /git/foo cd /git/foo git init git should return something like: Initialized empty Git repository in .git/ Your /git/foo path will likely be different than mine, but it doesn't really matter where you put stuff. I already had an /svn directory wi

# 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 some command line magic 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
   Recent articles
.rubyocop.yml
How-to build latest Linux kernel from Linus' git repo on Debian/Ubuntu
Visual Studio Code Configuration
Lots of great reasons to ditch the Electoral College
ignore latin1 problem via psql
   Tags
airplane (1) apache (1) apple (1) bash (2) bashrc (1) blackjack (1) callproof (1) college (1) config (1) console (1) data (1) debian (4) diff (1) django (2) electoral (1) enterprise (1) flying (1) freebsd (1) games (1) git (3) github (2) gmail (1) go-lang (3) google (1) gourse (1) kernel (3) latin1 (1) linux (4) lottery (1) microsoft (1) module (1) mongodb (1) mp3s (1) mutt (1) patch (1) photos (1) postgresql (2) powerball (1) psql (1) python (2) raspberrypi (1) rc (1) rubocopyml (1) sed (1) stack (1) sublime (1) testing (2) trace (1) ubuntu (2) utf8 (1) virus (1) visualstudiocode (1) vote (1) waylon (1)
   Twitter

Copyright © 2017 · GregDonald.io · All Rights Reserved