type readerFunc func(p []byte) (n int, err error)
func (rf readerFunc) Read(p []byte) (n int, err error) { return rf(p) }
func Copy(ctx context.Context, dst io.Writer, src io.Reader) error {
_, err := io.Copy(dst, readerFunc(func(p []byte) (int, error) {
select {
case <-ctx.Done():
return 0, ctx.Err()
Texto original em Inglês: https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f
- FWIW: Eu não produzi o conteúdo apresentado aqui (o esboço do livro de Edmond Lau). Acabei de copiar e colar de algum lugar da Internet, mas não me lembro qual é exatamente a fonte original. Também não consegui encontrar o nome do autor, por isso não posso lhe dar os devidos créditos. *
- Por Edmond Lau
- Altamente recomendado: +1:
Some of these practices might be based on wrong assumptions and I'm not aware of it, so I would appreciate any feedback.
-
avoiding some dependency conflicts:
- install sbt-explicit-dependencies globally in your
~/.sbt/{0.13,1.0}/plugins/plugins.sbt
- run
undeclaredCompileDependencies
and make the obvious missing dependencies explicit by adding them tolibraryDependencies
of each sub-project - (optionally) run
unusedCompileDependencies
and remove some obvious unused libraries. This has false positives, so; reload; Test/compile
after each change and ultimately run all tests to see that it didn't break anything - (optionally) add
undeclaredCompileDependenciesTest
to the CI pipeline, so that it will fail if you have some undeclared dependencies
- install sbt-explicit-dependencies globally in your
-
keeping dependencies up to date and resolving conflicts:
- install sbt-updates globally in your `~/.sbt/{0.13,1.0}/plugins/plugins.
A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.
Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having large commits and sharing them infrequently, in contrast, makes it hard to solve conflicts.
[ | |
{ | |
"name": "[Lorg.eclipse.jetty.servlet.ServletMapping;", | |
"allDeclaredFields": true, | |
"allPublicFields": true, | |
"allDeclaredMethods": true, | |
"allPublicMethods": true | |
}, | |
{ | |
"name": "org.slf4j.impl.StaticLoggerBinder", |
#!/bin/bash | |
echo "swf2mp4.sh - flash player to mp4 conversion script" | |
echo " * Requires gnash, mplayer2 and ffmpeg CLI tools" | |
echo " * Source https://stackoverflow.com/a/39304421 (Aleksey Kontsevich)" | |
SWFFILE=$1 | |
MP4FILE=${SWFFILE%.*}.mp4 | |
TMPFILE=$(cat /dev/urandom | tr -dc 'a-zA-Z' | fold -w 32 | head -n 1).bin |
; Path of Exile macros | |
; go to hideout | |
#IfWinActive, Path of Exile | |
^h:: Send {Enter}+{Home}^c/hideout{Enter}{Enter}^v{Escape} | |
; logout | |
#IfWinActive, Path of Exile | |
$^l:: Send {Enter}+{Home}^c/exit{Enter}{Enter}^v{Escape} |
--- | |
- name: Install MacOS Packages | |
hosts: localhost | |
become: false | |
vars: | |
brew_cask_packages: | |
- atom | |
- docker | |
- dropbox | |
- firefox |
// Package deepcopy provides a function for deep copying map[string]interface{} | |
// values. Inspired by the StackOverflow answer at: | |
// http://stackoverflow.com/a/28579297/1366283 | |
// | |
// Uses the golang.org/pkg/encoding/gob package to do this and therefore has the | |
// same caveats. | |
// See: https://blog.golang.org/gobs-of-data | |
// See: https://golang.org/pkg/encoding/gob/ | |
package deepcopy |