This has been moved to a blog post.
*.cbor | |
*.log | |
*.xml | |
*.yaml | |
*.json | |
*.msgpack | |
*.html | |
*.marshal | |
*.pickle | |
.tox |
* |
/* DeviceUID.h | |
#import <Foundation/Foundation.h> | |
@interface DeviceUID : NSObject | |
+ (NSString *)uid; | |
@end | |
*/ | |
// Device.m |
# encoding: UTF-8 | |
# Chiliproject to Redmine converter | |
# ================================= | |
# | |
# This script takes an existing Chiliproject database and | |
# converts it to be compatible with Redmine (>= v2.3). The | |
# database is converted in such a way that it can be run multiple | |
# times against a production Chiliproject install without | |
# interfering with it's operation. This is done by duplicating |
I've been looking for the best Linux backup system, and also reading lots of HN comments.
Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.
- It has a lot of management overhead and that's a problem if you don't have time for a full time backup administrator.
#!/bin/bash | |
set -euo pipefail | |
function myFunction() { | |
myCommand | |
return $? | |
} | |
retry=0 | |
maxRetries=5 |
This guide is a first draft (that will end up in the official docs) on writing resilient code for production with the Couchbase Java SDK. At the end, the reader will be able to write code that withstands bugs, latency issues or anything else that can make their application fail.
Note that lots of concepts can be applied for both synchronous and asynchronous access. When necessary, both patterns are discussed separately. Also, the focus is on database interaction, but if you are using RxJava as part of your stack you can apply most of the principles there as well (and should!).
When working with Observables, it is important to understand the difference between cold and hot. Cold Observables will start to emit events once a Observer subscribes, and will do it "fresh" for each Observer. Hot Observables instead are starting to emit data as soon as it becomes available, and will return the same (or parts of the same)
#!/usr/bin/python3 | |
# By Steve Hanov, 2011. Released to the public domain. | |
# Please see http://stevehanov.ca/blog/index.php?id=115 for the accompanying article. | |
# | |
# Based on Daciuk, Jan, et al. "Incremental construction of minimal acyclic finite-state automata." | |
# Computational linguistics 26.1 (2000): 3-16. | |
# | |
# Updated 2014 to use DAWG as a mapping; see | |
# Kowaltowski, T.; CL. Lucchesi (1993), "Applications of finite automata representing large vocabularies", | |
# Software-Practice and Experience 1993 |