See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope>
is optional
This is an Keras implementation of ResNet-152 with ImageNet pre-trained weights. I converted the weights from Caffe provided by the authors of the paper. The implementation supports both Theano and TensorFlow backends. Just in case you are curious about how the conversion is done, you can visit my blog post for more details.
ResNet Paper:
Deep Residual Learning for Image Recognition.
Kaiming He, Xiangyu Zhang, Shaoqing Ren, Jian Sun
arXiv:1512.03385
import functools | |
def force_async(fn): | |
''' | |
turns a sync function to async function using threads | |
''' | |
from concurrent.futures import ThreadPoolExecutor | |
import asyncio | |
pool = ThreadPoolExecutor() |
Lsyncd is a tool used to keep a source directory in sync with other local or remote directories. It is a solution suited keeping directories in sync by batch processing changes over to the synced directories.
So the generic use case is to keep a source directory in sync with one or more local and remote directories.
n02119789 1 kit_fox | |
n02100735 2 English_setter | |
n02110185 3 Siberian_husky | |
n02096294 4 Australian_terrier | |
n02102040 5 English_springer | |
n02066245 6 grey_whale | |
n02509815 7 lesser_panda | |
n02124075 8 Egyptian_cat | |
n02417914 9 ibex | |
n02123394 10 Persian_cat |
{0: 'tench, Tinca tinca', | |
1: 'goldfish, Carassius auratus', | |
2: 'great white shark, white shark, man-eater, man-eating shark, Carcharodon carcharias', | |
3: 'tiger shark, Galeocerdo cuvieri', | |
4: 'hammerhead, hammerhead shark', | |
5: 'electric ray, crampfish, numbfish, torpedo', | |
6: 'stingray', | |
7: 'cock', | |
8: 'hen', | |
9: 'ostrich, Struthio camelus', |
#include <opencv2/core/core.hpp> | |
#include <opencv2/highgui/highgui.hpp> | |
#include <opencv2/features2d/features2d.hpp> | |
#include <opencv2/imgproc/imgproc.hpp> | |
#include <opencv2/video/video.hpp> | |
#include <iostream> | |
using namespace cv; | |
using namespace std; |
echo $"Script Written by $(tput setaf 5)Bikram Hanzra$(tput sgr 0) ([email protected])"$ | |
if [ "$#" == 0 ] ; then | |
echo "$(tput setaf 1)We need at least 2 arguments" | |
echo "SYNTAX ./remove <file-name> <text-to-be-removed>" | |
echo "<text-to-be-removed> by default = www.it-ebooks.info$(tput sgr 0)" | |
exit | |
fi | |
if [ "$#" == 1 ] ; then |
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil