FashionTech

One create knit work with knitting machines and the AYAB shield. Therefore, the computer communicates with the machine. This communication shall be done, in the future, with this new library, the AYABInterface. Here are some design decisions: Complete vs. Incomplete The idea is to have the AYAB seperated from the knittingpattern format. The knittingpattern format is an incomplete format that can be extended for any use case.  In contrast, the AYAB machine has a complete instruction set. The knittingpattern format is a means to transform these formats into different complete instruction sets. They should be convertible but not mixed. Desciptive vs. Imperative The idea is to be able to pass the format to the AYABInterface as a description. As much knowledge about the behavior is capsuled in the AYABInterface module. With this striving, we are less prone to intermix concerns across the applications. Responsibilty Driven Design I see these separated responsibilities: A communication part focusing on the protocol to talk and the messages sent across the wire. It is an interpreter of the protocol, transforming it from bytes to objects. A configuration that is passed to the interface Different Machines types supported. Actions the user shall perform. Different Representations I see these representations: Commands are transferred across the wire. (PySerial) For each movement of a carriage, the needles are used and put into a new position, B or D. (communication) We would like to knit a list of rows with different colors. (interface) Holes can be described by a list of orders in which meshes are moved to other locations, i.e. on needle 1 we can find mesh 1, on needle 2 we find mesh 2 first and then mesh 3, so mesh 2 and mesh 3 are knit together in the following step The knitting pattern format. Actions and Information for the User The user should be informed about actions to take. These actions should not be in the form of text but rather in the form of an object that represents the action, i.e. ["move", "this carriage", "from right to left"]. This way, they can be adequately represented in the UI and translated somewhere central in the UI. Summary The new design separates concerns and allows testing. The bridge between the machine and the knittnigpattern format are primitive, descriptive objects such as lists and integers.

In this sprint for the kniteditor library we focused on automatic deployment for Windows and Mac. The idea: whenever a tag is pushed to Github, a new travis build is triggered. The new built app is uploaded to Github as an ".dmg" file. Travis Travis is configured with the ".travis.yml" file which you can see here: language: python # see https://docs.travis-ci.com/user/multi-os/ matrix: include: - os: linux python: 3.4 - os: osx language: generic allow_failures: - os: osx install: - if [ "$TRAVIS_OS_NAME" == "osx" ] ; then mac-build/install.sh ; fi script: - if [ "$TRAVIS_OS_NAME" == "osx" ] ; then mac-build/test.sh ; fi before_deploy: - if [ "$TRAVIS_OS_NAME" == "osx" ] ; then cp mac-build/dist/KnitEditor.dmg /Users/travis/KnitEditor.dmg ; fi deploy: # see https://docs.travis-ci.com/user/deployment/releases/ - provider: releases api_key: secure: v18ZcrXkIMgyb7mIrKWJYCXMpBmIGYWXhKul4/PL/TVpxtg2f/zfg08qHju7mWnAZYApjTV/EjOwWCtqn/hm2CfPFo= file: /Users/travis/KnitEditor.dmg on: tags: true condition: "\"$TRAVIS_OS_NAME\" == \"osx\"" repo: AllYarnsAreBeautiful/kniteditor Note that it builds both Linux and OSX. Thus, for each step one must distinguish. Here, only the OSX parts are shown. These steps are executed: Installation. The app and dmg files are built. Testing. The tests are shipped with the app in our case. This allows us to execute them at many more locations - where the user is. Before Deploy. Somehow Travis did not manage to upload from the original location. Maybe it was a bug. Thus, a absolute path was created for the use in (4). Deployment to github. In this case we use an API key. One could also use a password. Installation: #!/bin/bash # # execute with --user to pip install in the user home # set -e HERE="`dirname \"$0\"`" USER="$1" cd "$HERE" brew update echo "# install python3" brew install python3 echo -n "Python version: " python3 --version python3 -m pip install --upgrade pip echo "# install pygame" python3 -m pip uninstall -y pygame || true # locally compiled pygame version # see https://bitbucket.org/pygame/pygame/issues/82/homebrew-on-leopard-fails-to-install#comment-636765 brew install sdl sdl_image sdl_mixer sdl_ttf portmidi brew install mercurial || true python3 -m pip install $USER hg+http://bitbucket.org/pygame/pygame echo "# install kivy dependencies" brew install sdl2 sdl2_image sdl2_ttf sdl2_mixer gstreamer echo "# install requirements" python3 -m pip install $USER -I Cython==0.23 \ --install-option="--no-cython-compile" USE_OSX_FRAMEWORKS=0 python3 -m pip install $USER kivy python3 -m pip uninstall -y Cython==0.23 python3 -m pip install $USER -r ../requirements.txt python3 -m pip install $USER -r ../test-requirements.txt python3 -m pip install $USER PyInstaller ./build.sh $USER The first step is to update brew. It cost me 4 hours to find this bug, 2 hours to work around it before. If brew is not updated, Python 3.4 is installed instead of Python 3.5. Then, Python, Pygame as the window provider for Kivy is installed, and the other requirements. It goes on with the build step. While installation is executed once on a personal Mac, the build step is executed several times, when the source code is changed. #!/bin/bash # # execute with --user to make pip install in the user home # set -e HERE="`dirname \"$0\"`" USER="$1" cd "$HERE" ( cd .. echo "# removing old installation of kniteditor" python3…