#Stay Standalone
A short script to prevent internal links to a "webapp" added to iPhone home screen to open in Safari instead of navigating internally.
#Stay Standalone
A short script to prevent internal links to a "webapp" added to iPhone home screen to open in Safari instead of navigating internally.
#Mobile Device Detection via User Agent RegEx
Yes, it is nearly 2012 and this exercise has been done to death in every imaginable language. For my own purposes I needed to get the majority of non-desktop devices on to a trimmed down, mobile optimized version of a site. I decided to try and chase down an up-to-date RegEx of the simplest thing that could possibly work.
I arrived at my current solution after analyzing 12 months of traffic over 30+ US based entertainment properties (5.8M+ visitors) from Jan - Dec 2011.
The numbers solidified my thoughts on the irrelevancy of including browsers/OSes such as Nokia, Samsung, Maemo, Symbian, Ipaq, Avant, Zino, Bolt, Iris, etc. The brass tacks of the matter is that you certainly could support these obscure beasts, but are you really going to test your site on them? Heck, could you even find one?! Unless the folks that pay you are die hard Treo users my guess is "No".
Interestingly enough my research shows that /Mobile/ is more efficient than **/iP(
# xcode-build-bump.sh | |
# @desc Auto-increment the build number every time the project is run. | |
# @usage | |
# 1. Select: your Target in Xcode | |
# 2. Select: Build Phases Tab | |
# 3. Select: Add Build Phase -> Add Run Script | |
# 4. Paste code below in to new "Run Script" section | |
# 5. Drag the "Run Script" below "Link Binaries With Libraries" | |
# 6. Insure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0) |
/* CGSPrivate.h -- Header file for undocumented CoreGraphics stuff. */ | |
/* This file is a relicensed portion of DesktopManager and was originally released under | |
* the terms of the GNU General Public Licence. Original licence text follows the new terms. | |
* The contents of this file has been re-released by the original author under the following terms: | |
* | |
* Copyright (C) 2003, 2004, 2013 Richard J Wareham <[email protected]> | |
* | |
* Permission is hereby granted, free of charge, to any person obtaining a copy of this | |
* software and associated documentation files (the "Software"), to deal in the Software |
This means, on your local machine, you haven't made any SSH keys. Not to worry. Here's how to fix:
*nix
based command prompt (but not the default Windows Command Prompt!)cd ~/.ssh
. This will take you to the root directory for Git (Likely C:\Users\[YOUR-USER-NAME]\.ssh\
on Windows).ssh
folder, there should be these two files: id_rsa
and id_rsa.pub
. These are the files that tell your computer how to communicate with GitHub, BitBucket, or any other Git based service. Type ls
to see a directory listing. If those two files don't show up, proceed to the next step. NOTE: Your SSH keys must be named id_rsa
and id_rsa.pub
in order for Git, GitHub, and BitBucket to recognize them by default.ssh-keygen -t rsa -C "[email protected]"
. ThOne 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
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
@import AVFoundation; | |
#import "ViewController.h" | |
@interface ViewController () | |
@property (nonatomic)AVCaptureSession *session; | |
@end | |
@implementation ViewController | |
- (void)viewDidLoad |