| #!/bin/bash | |
| # | |
| # The MIT License (MIT) | |
| # | |
| # Copyright (c) 2018 Mathias Leppich <mleppich@muhqu.de> | |
| # | |
| # 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 without restriction, including without limitation the rights | |
| # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell |
| local PRESSED = {}; | |
| local MAPPING = {}; | |
| MAPPING[4] = "F13"; | |
| MAPPING[5] = "F14"; | |
| MAPPING[6] = "F15"; | |
| local DPI_TABLE={800, 1900, 2800} | |
| local DPI_TABLE_LEN=table.getn(DPI_TABLE) |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <title></title> | |
| <style type="text/css"> | |
| body { | |
| margin: 0; padding: 1px 2px; | |
| white-space: nowrap; | |
| width: 90px; | |
| } |
This shell script uses imagemagick's convert tool to extract the aws service icons from the sprite image that is used by the AWS Management Console.
https://d34xub3ut0ooib.cloudfront.net/img/sprite.74912210ecce3b8cc2a8e53158f698f1.png
| #!/bin/bash | |
| # | |
| # The MIT License (MIT) | |
| # | |
| # Copyright (c) 2015 Mathias Leppich <mleppich@muhqu.de> | |
| # | |
| # 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 without restriction, including without limitation the rights | |
| # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell |
| { | |
| "AWSTemplateFormatVersion" : "2010-09-09", | |
| "Description" : "", | |
| "Parameters" : { | |
| "InstanceType" : { | |
| "Description" : "", | |
| "Type" : "String", | |
| "Default" : "t2.micro", |
I had a misconception about couchdb's conflict management. I was under the impression that couchdb handles document deletes in the same way as document updates. In fact a delete creates just another revison that marks the document as deleted, also known as the tombstone revision.
When a document gets modified after replication, on both databases (source and target), and the document gets replicated again from source to target, it will be in conflict state. This is also true for a document that has been updated on the target and deleted from source. The document's tombstone revision gets replicated, but as couchdb's way of resolving conflicts is to 'delete' the unwanted revision, the just replicated tombstone revison is implicitly considered as the unwanted (or loosing) revision in this conflict. So the conflict is implicitly resolved by picking the revision that has not been deleted. The document in the target db doesn't show any _conflicts field but it shows the replicated tombstone rev in the `_
| #!/bin/sh | |
| main() { | |
| TITLE="$(eclipseWindowTitle)" | |
| if [[ -z "$TITLE" ]]; then | |
| error "no title" | |
| exit 1; # no title | |
| fi | |
| WORKSPACE="$(echo "$TITLE" | awk -F ' - ' '{print $(NF)}')" |
$ PORT=1234 http2json &
[1] 52577
$ curl -X GET :1234/HelloWorld
{"Time":1414602104,"Method":"GET","URL":"/HelloWorld","Body":null}
ok
$ curl -X PUT :1234/Foo -d Bar
{"Time":1414602240,"Method":"PUT","URL":"/Foo","Body":"Bar"}
| { | |
| "AWSTemplateFormatVersion" : "2010-09-09", | |
| "Description" : "AWS CloudFormation Sample Template", | |
| "Parameters" : { | |
| "InstanceType" : { | |
| "Description" : "WebServer EC2 instance type", | |
| "Type" : "String", | |
| "Default" : "m1.small", |