One 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
One-way data synchronisation is trivial. Forward all mutating operations to your slave store to also perform them. Master-Slave replication complete.
Two-way data synchronisation - on the other hand - is hard. It involves conflict resolution, varying of complexity, from choosing the newest operation, most relavant operation, or using operational transforms. All of these require vaguely accurate time synchronisation which then produce another set of problems, solvable with comparing timers, using a shared time server, or using [atomic clocks][1].
Currently, I'm trying to synchronise session data across multiple authentication servers. I've added to the complexity of the problem by assuming that each node is transient and may only exist for a limited amount of time (i.e. AWS deciding they need to unplug my instance). Also, the connections between each node may fail.
| for f in /usr/local/Cellar/ogre/1.8.1/lib/*.1.8.1.dylib | |
| do | |
| echo $f | |
| sudo install_name_tool -change @executable_path/../Frameworks/Ogre.framework/Versions/1.8.1/Ogre /usr/local/Cellar/ogre/1.8.1/lib/Release/Ogre.framework/Ogre $f | |
| sudo install_name_tool -change @executable_path/../Plugins/Plugin_PCZSceneManager.1.8.1.dylib /usr/local/Cellar/ogre/1.8.1/lib/Plugin_PCZSceneManager.1.8.1.dylib $f | |
| sudo install_name_tool -change @executable_path/../Components/libOgrePaging.1.8.1.dylib /usr/local/Cellar/ogre/1.8.1/lib/libOgrePaging.1.8.1.dylib $f |
ror, scala, jetty, erlang, thrift, mongrel, comet server, my-sql, memchached, varnish, kestrel(mq), starling, gizzard, cassandra, hadoop, vertica, munin, nagios, awstats
| license: gpl-3.0 | |
| height: 960 | |
| border: no | |
| redirect: https://observablehq.com/@d3/d3-chord-diagram |
| Here is what you need to do to register your app for a custom URL scheme (for the example we will use a "myapp" scheme). | |
| 1) In your Info.plist, add a new entry for CFBundleURLTypes: <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>MyApp's URL</string> <key>CFBundleURLSchemes</key> <array> <string>myapp</string> </array> </dict> </array> | |
| 2) Somewhere in your application's startup code (e.g. init), add this code: - (void)registerMyApp { [[NSAppleEventManager sharedAppleEventManager] setEventHandler:self andSelector:@selector(getUrl:withReplyEvent:) forEventClass:kInternetEventClass andEventID:kAEGetURL]; } | |
| - (void)getUrl:(NSAppleEventDescriptor )event withReplyEvent:(NSAppleEventDescriptor )replyEvent { NSString url = [[event paramDescriptorForKeyword:keyDirectObject] stringValue]; // Now you can parse the URL and perform whatever action is needed } | |
| Related Tidbits: |
| The po command stands for "print object." | |
| The symbol $eax refers to one of the CPU registers. In the case of an exception, this register will contain a pointer to the NSException object. | |
| Note: $eax only works for the simulator, if you’re debugging on the device you’ll need to use register $r0. | |
| (lldb) po [$eax class] | |
| You will see something like this: | |
| (id) $2 = 0x01446e84 NSException | |
| You can call any method from NSException on this object. For example: |
| #!/usr/bin/env python | |
| """Simple HTTP Server With Upload. | |
| This module builds on BaseHTTPServer by implementing the standard GET | |
| and HEAD requests in a fairly straightforward manner. | |
| """ |
