"https://breakingbytes.github.io/".For the how and why I am making this move from Google Blogger to Pelican and GitHub Pages, please read my first post.
Moving to Pelican at GitHub PagesGood bye Google Blogger, you've served me well. And for anyone following Poquito Picante, I hope to see you soon at Breaking Bytes.
There are many blog posts on the topic of effective Git workflows, SO questions and answers, BitBucket tutorials and GitHub guides and an article that has been archived by former BBC Mark McDonnell. So why another post on git workflow? None of these workflows seemed right for us, but recently it's just clicked, and I feel like we've finally found the process that works for us. The key was finding the simplest workflow that included the most valuable best practices. In particular, we found that complicated multi-branch strategies were unnecessary, but test driven development (TDD) and continuous integration (CI) were a must.
We start with the assumption that all of collaborators fork the upstream repository to their personal profile. Then each person clones their profile to their laptop as origin and adds another remote pointing to the upstream repository. For convenience, they may also create remotes to the forks of their most frequent collaborators.
[myusername@mycomputer ~/Projects] $ git clone git@github.com:myusername/myrepo.git [myusername@mycomputer ~/Projects] $ cd myrepo [myusername@mycomputer ~/Projects/myrepo] $ git remote add upstream git@github.com:mycompany/myrepo.git [myusername@mycomputer ~/Projects/myrepo] $ git remote add mycollaborator git@github.com:mycollaborator/myrepo.git [myusername@mycomputer ~/Projects/myrepo] $ git remote show origin upstream mycollaborator
The next assumption is that we all keep our version of master synchronized with upstream master. And we never work out of our own master branch! Basically this means at the start of any new work we do the following:
git fetch --all to get the lay of the land. This combined with git log --all --graph --date=short --pretty=format:"%ad %h %s%d [%an]"
I'm also going to assume that everyone is following the recommended project layout. This means that their project has all dependencies listed in requirements.txt, is developed and deployed in its own virtual environment, includes testing and documentation that aims for >80% coverage, has a boilerplate design that allows testing, documentation and package data to be bundled into a distribution and enables use with a test runner with self discovery, and is written with docstrings for autodocumentation. Nothing is ever perfect, so being diligent of path clashes, aware of the arcana of Mac OS X1 or Windows2 and able to use Stack Overflow to find answers is still important.
This is key. Set up Travis, Circle, AppVeyor or Jenkins on upstream master to test and build every commit, every commit to an open PR and to deploy on every tag. Easy!
There are some features of this style that stand out:
PYTHONHOME=/home/you/path/to/project/venv/ python instead of using source venv/bin/activate.nosetests script will use your system Python and therefore the Python path will not include your virtual environment. The solution is to never use system site packages and install all dependencies directly in your virtual environment.
In fact as soon as you assign a value to any element in the object array it grows the array to that size, which allocates (or reallocates) RAM for the new object array, therefore defeating the point of preallocating space.
From Empty Arrays section of OOP documentation:
“If you make an assignment to a property value, MATLAB calls the SimpleClass constructor to grow the array to the require size:”
Instead if you want to preallocate space for an object array, grow the array once by assigning the last object first. This requires the class to have a no-arg constructor. Each time you grow your array you will reallocate RAM for it, wasting time and space, so do it once with the max expected size of the array. See Initialize Object Arrays and Initializing Arrays of Handle Objects in the OOP documentation.
>> S(max_size) = MyClass(args)
Another option is to preallocate any other container like a cell array (best IMHO), structure or containers.Map and then fill in the class objects as they are created. An advantage to this is you don’t have to subclass matlab.mixin.Heterogeneous to group different classes together.
>> S = cell(max_size); args = {1,2,3;4,5,6;7,8,9};
>> for x = 1:size(args,1), S(x) = MyClass(args{x,:});end
The only time to use an empty object is if you want it as a default for the situation where nothing gets instantiated, and you need the it be an instance of the class. Of course any empty array will do this, IE: '', [] and {} are also empty.
>> S = MyClass.empty >> if blah,S = MyClass(args);end >> if isa(S, 'MyClass') && isempty(S),do stuff; end
I hope this helps someone; it definitely helped me understand the odd nature of MATLAB. This behavior is because everything in MATLAB is an array, even a scalar is a <1x1 double> read the C-API mxArray for external references and mwArray for compiled/deployed MATLAB for more info.
MATLAB = Matrix LaboratoryClass definitions didn’t appear until 2008. Other languages like C++, Java, Python and Ruby are object first. So the empty method is meant to duplicate the ability to be empty similar to other MATLAB datatypes such as double, cell, struct, etc. IMO outside of MATLAB it's a very artificial and somewhat meaningless construct.
[UPDATE 2018-09-04] Links to Cookiecutter and Bootstrap a Scientific Python Library from the National Synchrotron Light Source II (NLSL-II).
[UPDATE 2016-07-19] Lately I've preferred using core instead of lib for the main package modules.
[UPDATE 2015-06-04] Create top level package to bundle all sub-packages and package-data together for install.
Been looking for a good, comprehensive, credible guide:
This is a tutorial with a template for packaging, testing, documenting, and publishing scientific Python code.
A command-line utility that creates projects from cookiecutters (project templates), e.g. creating a Python package project from a Python package project template.
It's hard to pin a standard style down. Here’s mine:
MyProject/ <- git repository
|
+- .gitignore <- *.pyc, IDE files, venv/, build/, dist/, doc/_build, etc.
|
+- requirements.txt <- to install into a virtualenv
|
+- setup.py <- use setuptools, include packages, extensions, scripts and data
|
+- MANIFEST.in <- files to include in or exclude from sdist
|
+- readme.rst <- incorporate into setup.py and docs
|
+- changes.rst <- release notes, incorporate into setup.py and docs
|
+- myproject_script.py <- script to run myproject from command line, use Python
| argparse for command line arguments put shebang
| `#! /usr/bin/env python` on 1st line and end with a
| `if __name__ == "__main__":` section, include in
| setup.py scripts section for install
|
+- any_other_scripts.py <- scripts for configuration, documentation generation
| or downloading assets, etc., include in setup.py
|
+- venv/ <- virtual environment to run tests, validate setup.py, development
|
+- myproject/ <- top level package keeps sub-packages and package-data together
| for install
|
+- __init__.py <- contains __version__, an API by importing key modules,
| classes, functions and constants, __all__ for easy import
|
+- docs/ <- use Sphinx to auto-generate documentation
|
+- tests/ <- use nose to perform unit tests
|
+- other_package_data/ <- images, data files, include in setup.py
|
+- core/ <- main source code for myproject, sometimes called `lib`
| |
| +- __init__.py <- necessary to make mypoject_lib a sub-package
| |
| +- … <- the rest of the folders and files in myproject
|
+- related_project/ <- a GUI library that uses myproject_lib or tools that
| myproject_lib depends on that's bundled together, etc.
|
+- __init__.py <- necessary to make related_project a sub-package
|
+- … <- the rest of the folders and files in your the related project
If for some bizarre reason you find yourself looking for a YA dystopian novel set in SF in modern times, then you can read Cory Doctorow's Homeland, and its prequel Little Brother for free (if you don't mind plugs by the author for independent brick'n'mortar bookshops nationwide between chapters).
For my teaching friends, there is a study guide for high school students and another one for Little Brother.
All of Cory Doctorow's (of Boing Boing and xkcd fame) novels are available free for download on his craphound website.
I used the epub file in the Nook reader app on my Android phone. I just dropped the file in the Nook's "My Documents folder". The epub file is unfortunately incorrectly formatted for Google books. For an Amazon Kindle compatible version scroll to the bottom for the mobi file.
Maybe enjoy? (I did, but beware the themes hit very close to home. That's good right?)
