| defaults write ~/.MacOSX/environment.plist M2_HOME `brew --prefix maven`/libexec | |
| defaults write ~/.MacOSX/environment.plist M2 `brew --prefix maven`/libexec/bin |
| # Install ARCH Linux with encrypted file-system and UEFI | |
| # The official installation guide (https://wiki.archlinux.org/index.php/Installation_Guide) contains a more verbose description. | |
| # Download the archiso image from https://www.archlinux.org/ | |
| # Copy to a usb-drive | |
| dd if=archlinux.img of=/dev/sdX bs=16M && sync # on linux | |
| # Boot from the usb. If the usb fails to boot, make sure that secure boot is disabled in the BIOS configuration. | |
| # Set swedish keymap |
| android.libraryVariants.all { variant -> | |
| def name = variant.buildType.name | |
| if (name.equals(com.android.builder.BuilderConstants.DEBUG)) { | |
| return; // Skip debug builds. | |
| } | |
| def task = project.tasks.create "jar${name.capitalize()}", Jar | |
| task.dependsOn variant.javaCompile | |
| //Include Java classes | |
| task.from variant.javaCompile.destinationDir | |
| //Include dependent jars with some exceptions |
#The Functional Programmers Cheat Sheet for NDC Oslo 2014
This year NDC Oslo has a full three-day functional programming track with an amazing lineup. If you agree that the future of programming is FP, use this as your "auto pilot" guide on what sessions to attend.
Cheer for sessions on Twitter using the #ndcoslo and #fptrack hashtags.
[The full agenda (including non-fp sessions) is here].
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.
Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories
Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.
This method avoids merge conflicts if you have periodically pulled master into your branch. It also gives you the opportunity to squash into more than 1 commit, or to re-arrange your code into completely different commits (e.g. if you ended up working on three different features but the commits were not consecutive).
Note: You cannot use this method if you intend to open a pull request to merge your feature branch. This method requires committing directly to master.
Switch to the master branch and make sure you are up to date:
| " Minimal neovim configuration for go | |
| " | |
| " deoplete requires neovim, so this will not work with regular vim | |
| " | |
| " prereqs: | |
| " - neovim | |
| " - neovim python3 (pip3 install --upgrade neovim) | |
| " | |
| " includes: | |
| " - syntax checking on save (using neomake, go and gometalinter) |
| package main | |
| import ( | |
| "fmt" | |
| "net/http" | |
| "sort" | |
| "time" | |
| ) | |
| // a struct to hold the result from each request including an index |
