class IOHelper { | |
public byte[] readBytes(InputStream inputStream) throws IOException { | |
// this dynamically extends to take the bytes you read | |
ByteArrayOutputStream byteBuffer = new ByteArrayOutputStream(); | |
// this is storage overwritten on each iteration with bytes | |
int bufferSize = 1024; | |
byte[] buffer = new byte[bufferSize]; | |
// we need to know how may bytes were read to write them to the byteBuffer |
public class ProgressRequestBody extends RequestBody { | |
private File mFile; | |
private String mPath; | |
private UploadCallbacks mListener; | |
private static final int DEFAULT_BUFFER_SIZE = 2048; | |
public interface UploadCallbacks { | |
void onProgressUpdate(int percentage); | |
void onError(); |
If referential integrity has been broken:
git config --get remote.origin.url
If referential integrity is intact:
git remote show origin
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.
pull requests make it incredibly easy for your team to comment on each other’s work.
link: Git Feature Branch Workflow
git checkout master
For this I'd use:
gitk [filename]
or to follow filename past renames
gitk --follow [filename]
(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.
module Jekyll | |
Page.class_eval { | |
def clone | |
Page.new(@site, @base, @dir, @name) | |
end | |
} |