DEV Community: Sascha Becker

Material Design 2 — more than just rounded corners

Sascha Becker — Fri, 11 May 2018 14:50:00 +0000

Material Design

Google first showed it’s vision for the next UI principles in 2014.

So with Google I/O 2018 an iterativ version of material design was published.

Many things were left untouched, which is good because it worked well so far. Some things are now tweaked and enhanced to provide better freedom for creative UI designers. And some new stuff was added. Let’s break it down.

Goals

The first version of the Material Design guidelines had two fundamental goals which it achieved very well over the past few years.

Create

Create a visual language that synthesizes classic principles of good design with the innovation and possibility of technology and science.

Unify

Develop a single underlying system that allows for a unified experience across platforms and device sizes. Mobile precepts are fundamental, but touch, voice, mouse, and keyboard are all ﬁrst-class input methods.

If you want to read more about the first version, head over to the archived guidelines.

Introduction - Material Design

Designs that adopted the Material Design guidelines were pretty intuitive. But they had one thing in common, they looked and felt nearly all the same. You might argue that this a good thing, but if you want to present your brand, it’s certainly not. That’s why Google added a third goal this year.

Customize

Expand Material’s visual language and provide a flexible foundation for innovation and brand expression. Take a look at the talk to see what can be now achieved by just making a few tweaks.

Principles

Material Design started with three very important key principles.

Material is the metaphor

Material Design is inspired by the physical world and its textures, including how they reflect light and cast shadows. Material surfaces reimagine the mediums of paper and ink.

Bold, graphic, intentional

Material Design is guided by print design methods — typography, grids, space, scale, color, and imagery — to create hierarchy, meaning, and focus that immerse viewers in the experience.

Motion provides meaning

Motion focuses attention and maintains continuity, through subtle feedback and coherent transitions. As elements appear on screen, they transform and reorganize the environment, with interactions generating new transformations.

Two new principles

To achieve the new goal of customization, they had to expand that list a bit.

Flexible foundation

The Material Design system is designed to enable brand expression. It’s integrated with a custom code base that allows the seamless implementation of components, plug-ins, and design elements.

Cross-platform

Material Design maintains the same UI across platforms, using shared components across Android, iOS, Flutter, and the web.

Colors

Color - Style - Material Design

That’s how it started. A predefined color palette and I, as a developer, was happy that my decisions were made so easy. It even says so in the video title!

And now, for the new goal and principles, we have the choice for even more colors. Like all the colors. Want your app to be purple but kinda blue? No problem, go for it!

So they defined three principles for colors.

Hierarchical

Color indicates which elements are interactive, how they relate to other elements, and their level of prominence. Important elements should stand out the most.

Legible

Text and important elements, like icons, should meet legibility standards when appearing on colored backgrounds, across all screen and device types.

Expressive

Reinforce your brand by showing brand colors at memorable moments that reinforce your brand’s style.

The color system

Shape

Up until now we had round buttons, slightly round corners and hard corners. Now we can have every combination with various settings involved.

Material surfaces have a rectangular shape by default, with 4dp rounded corners. They have adjustable:

Corner angles and curves
Edge angles and curves
The number of corners

Shape changes, such as rounded or clipped corners, can be subtle or more significant.

About shape

Components

App bar

We already know and love the app bar. It’s placed at the top and provides space for our burger menu icon, a title and various actions we need.

But you know what loves the top space? The notch. Oh the glorious notch. You may noticed the iPhone X UI tweaks to integrate the notch better into current designs. And it’s coming to android, too. Scaled page titles and all the top actions are now on the bottom. They don’t say it but that’s why the app bar bottom was introduced.

It shifts the current app bar to bottom and basically acts like normal. But what about a FAB (Floating Action Button). Doesn’t it get in the way you may ask?Yes, it would. So they just merged it.

There are various variants on how the FAB is placed and its visual appeal. It can even be placed in a cutout.

App bars: bottom

Button

What’s the primary action on this page? That’s what every designer asked in the past. And in most cases it was very easy to define what’s a primary and what’s more a secondary action. Use flat buttons if you need less prominence and raised buttons for more prominence.

With material design 1 we had flat buttons and raised buttons. In combination with the primary or secondary color a distinction was easy to make. But sometimes we wished for a “in-between” button to display a special use case. That’s what’s new!

They renamed flat buttons to text buttons and raised buttons to contained buttons. And they called the “in-between” button outlined button.

This will make different emphasis easier to display and gives designers more options to work with.

Buttons

Sheet

Oh the lovely sheet. Drawers’ little brother. It is basically just a paper element which would raise from the button to display beautiful actions or details. In some cases it is even persistent and provides actions used in media playback.

Some designs needed to display options on the side. Like filters, sort options or additional details. We had to build this ourselves. But no more my friend. I introduce the sheet on the side!

It works just like the bottom sheet but now on the side. Use it in a persistent state or like a modal and let it overlap your content.

Sheets: side

Backdrop

This is a completely new component. It combines the content displayed in the front layer with details, filters or other actions related to that content in the back layer.

Backdrop

Text fields

Input fields just had a label, its input area and an underline. Now there are two options to use. Filled text and outlined text.

Filled text fields carry more visual emphasis, making them stand out when surrounded by other content and components.

Outlined text fields have less visual emphasis than filled text fields, which helps simplify layout in places like forms, where many text fields are placed together.

Text fields

Conclusion

Many subtle but very important changes for achieving the new goal towards more customization. Also really cool new additions which will address past confusion.

These changes will lead to different variations and adaptions of the standards while still look and feel different.

For me as a developer and designer it’s still a big pill to swallow as I just thought I mastered material design 1. But change and progress is good for everyone.

A cryptocurrency trading bot that doesn’t scam you

Sascha Becker — Tue, 14 Nov 2017 15:45:12 +0000

Cryptocurrency trading bots are becoming the next big thing people think they need. And so they buy one. So did I.

This is not a copy & pasta example. It’s more a guideline on how to achieve what you want

Step 0: Learn throwing money away the hard way

Investing in a third party cryptocurrency trading bot makes you feel you did the right thing. You can become finally rich by doing nothing. The bot will make money for you, right? Wrong!

You just gave away money to buy this bot to make the developer rich. And he does nothing, except some updates here and there. So in that way he does make money with a cryptocurrency bot.

But you are still not rich. Dang it! What to do?

Step 1: Write your own

The only bot you should trust comes from a codebase you build. It comes from a logic and pattern you invented. Don’t let anyone tell you what’s right.

I coded one and you can, too! So let’s get started. (Spoiler: I’m not rich, yet)

You can also clone my github repo if you want.

https://github.com/TeamWertarbyte/crypto-trading-bot

Step 2: Find a good cryptocurrency trading market

This is the hardest part. Find a good place for your bot to trade on. Good starting points are either bittrex or kraken. The both have good APIs to work on.

https://bittrex.com/Home/Api

Kraken | Buy, Sell and Margin Trade Bitcoin (BTC) and Ethereum (ETH) - API

Create an account and let’s get to the next step.

Step 3: Define the bot environment

For my bot I stuck with bittrex.com It has a solid API and good response times. They also provide a websocket for live updates.

The framework I’m using for this example is node js. But you can choose whatever you like. I wanted to have it run via docker-compose in the command line. So node js was a good pick.

The API can be accessed via a npm package like

dparlevliet/node.bittrex.api

Or you write your own REST client to access bittrex. The documentation for the API in bittrex is quite outdated. It is for version 1.1 which is in use for quite some time now. Bittrex also accepts calls from, the not yet official released, version 2.0. The mentioned package for node does a pretty good job implementing the shiny new 2.0 calls. Use that!

Step 4: Define your trade logic

As you want to crunch the numbers you some market indicators. For me it was the EMA (Exponential Moving Average) value. You can read more about other values here:

Market Indicators [ChartSchool]

I chose two market indicators on an hour basis.

(RED) EMA with a period of 50
(BLUE) EMA with a period of 15

Alone they are not very effective. But look at those points where they cross. They are the ideal entry or exit points for buy or sell orders.

So my trade logic was clear

Buy if EMA 15 is greater than EMA 50 and sell if EMA 50 is greater than EMA 15. This way my money is always in altcoins that are raising and once they fall sell it back to bitcoin.

This is just one out of dizillion combinations. Try what’s best for you. I’m working on an AI that detects the best market indicators and creates new ones but that will be another post.

Step 5: Docker

Your bot has to run 24/7 otherwise you won’t be profitable. So I wrapped my bot in a docker compose which runs forever.

Dockerfile:

FROM node:latest

# Create app directory
RUN mkdir - p / usr / src / app
WORKDIR / usr / src / app

# Install app dependencies
COPY package.json / usr / src / app/  
RUN npm install

# Bundle app source
COPY. / usr / src / app

RUN npm run build
CMD ["npm", "start"]

docker-compose.yml

version:'2'
services:  
 server:  
 build:.
restart:'unless-stopped'

Step 6: The loop

Let’s define the loop and its configs. I will explain every loop action step by step so be patient. Our config object will grow over time. Our constructor creates three internal variables.

bittrex — The access point to the bittrex api
currencies — Holds our populated coins, its values, market indicators and everything else coin related
bitcoin — It’s just the extracted bitcoin coin from the currencies

I use bluebird as my promise library because of concurrency control.

const now = require('performance-now')
const Promise = require('bluebird')
const log = require('fancy-log')

Promise.config({
 cancellation: true  
})

const configs = {
 cancelOpenOrdersOnStart: true,
 refreshTimeout: 180000 // 3 minutes
}

const INVEST\_HOLD\_OR\_REJECT = {
 HOLD: 'HOLD',
 INVEST: 'INVEST',
 REJECT: 'REJECT',
 NONE: 'NONE'
}

export default class Watcher {
 constructor (bittrex) {
this.bittrex = bittrex
this.currencies = []
this.bitcoin = {}
 }

async watch () {
const start = now()
 log.info(`## Started emma watch ##`)

 configs.cancelOpenOrdersOnStart && await this.cancelOldOrders()

await this.fetchMarkets()
await this.fetchBalances()

await this.injectMarketSummaries( this.currencies)
await this.filterCurrenciesByMarkets(configs.markets)
await this.injectCandleData( this.currencies)
await this.injectMarketIndicators( this.currencies)
await this.countEmaCrossPointTicks( this.currencies)
await this.injectClosedOrderHistory( this.currencies)

await this.injectMarketSummaries( this.currencies)
await this.evaluateInvestHoldOrReject( this.currencies)

await this.rejectBadInvestments( this.currencies)
await this.invest( this.currencies)

 log.info(`## Finished ${(now() - start).toFixed(5)} ms ##`)
 setTimeout(() =\> this.watch(), configs.refreshTimeout)
 }
}

Step 6.1: Cancel old orders

Orders made by our bot may not always go through. So we have to cancel old orders if they won’t be accepted.

async cancelOldOrders () {
const start = now()
const openOrders = await this.bittrex.getOpenOrders()

if (openOrders.length \> 0) {
for ( let openOrder of openOrders) {
const elapsedHours = ( new Date() - new Date(openOrder.Opened)) / 1000 / 60 / 60
if (elapsedHours \> configs.maxHoursToHoldOrder) {
 log.info(`Cancel ${openOrder.OrderType} on ${openOrder.Exchange} du to older than ${configs.maxHoursToHoldOrder} hours`)
await this.bittrex.cancel({uuid: openOrder.OrderUuid})
 }
 }
 log.info(`Canceled old orders ${(now() - start).toFixed(5)} ms`)
 }
}

I added a config variable to control elapsed hours to hold an order.

const configs = {
 cancelOpenOrdersOnStart: true ,
 maxHoursToHoldBalance: 168, // 7 days
 refreshTimeout: 180000, // 3 minutes
}

Step 6.2: Populate the currencies

We fetch the current markets and filter only the BTC markets. I don’t support ETH markets for now.

async fetchMarkets () {
const start = now()
this.currencies = await this.bittrex.getMarkets()

 // remove other market than BTC for now
this.currencies = this.currencies.filter(c =\> c.BaseCurrency === 'BTC')
 log.info(`Fetched currencies ${(now() - start).toFixed(5)} ms`)
}

Then we need to inject the current balances of the coins to see their actual value from our wallet. I also separate bitcoin at this stage.

async fetchBalances () {
const start = now()
const balances = await this.bittrex.getBalances()
for ( let currency of this.currencies) {
const balance = balances.find((b) =\> b.Currency === currency.MarketCurrency)
if (balance) {
 currency.balance = balance
 } else {
 currency.balance = null  
}
 }

this.bitcoin = balances.find((b) =\> b.Currency === 'BTC')

 log.info(`Fetched balances ${(now() - start).toFixed(5)} ms`)
}

Step 6.3: Get market live data

To get get BID, ASK and LATEST we need to inject the market summaries into our currencies.

async injectMarketSummaries (data) {
const start = now()

const marketSummaries = await this.bittrex.getMarketSummaries({\_: Date.now()})

await Promise.map(data, async (d) =\> {
const marketSummary = marketSummaries.find((ms) =\> d.BaseCurrency === ms.Market.BaseCurrency && d.MarketCurrency === ms.Market.MarketCurrency)
 d.marketSummary = marketSummary.Summary
 })

 log.info(`Injected market summaries ${(now() - start).toFixed(5)} ms`)
}

Step 6.4: Filter your currencies

I added specific markets where I want to trade on.

const configs = {
 cancelOpenOrdersOnStart: true ,
 maxHoursToHoldOrder: 0.5,
 refreshTimeout: 180000, // 3 minutes
 markets: [
 'ADA',
 'BCC',
 'DASH'
 ]
}

You can filter also by volume or a specific BTC value. Or you just don’t filter and trade with all available coin.

async filterCurrenciesByMarkets (markets) {
const start = now()

this.currencies = this.currencies.filter(c =\> markets.includes(c.MarketCurrency) || (c.balance && c.balance.Available \> 0))

 log.info(`Filtered currencies by selected markets ${(now() - start).toFixed(5)} ms`)
}

Step 6.5: Light the candles

To crunch some market indicators we need the candles. A candle describes a value for the selected market in a timeframe with a given step interval.

http://globaltrendtraders.com/technical-analysis/technical-analysis-of-stock-trends-1-chart-types/

You can read more about candles here:

Technical Analysis of Stock Trends #1 - Chart Types

async injectCandleData (data) {
const start = now()
const \_ = Date.now()

const USDT\_BTC = await this.bittrex.getCandles({
 marketName: 'USDT-BTC',
 tickInterval: configs.tickInterval,
 \_
 })

await Promise.map(data, async (d) =\> {
 d.candles = await this.bittrex.getCandles({
 marketName: `BTC-${d.MarketCurrency}`,
 tickInterval: configs.tickInterval,
 \_
 })

 d.candles = d.candles.map((c, i) =\> this.parseCandleData(c, USDT\_BTC[i]))
 }, {concurrency: 15})

 log.info(`Injected candle data ${(now() - start).toFixed(5)} ms`)
}

parseCandleData (d, USDT\_BTC) {
return {
 date: parseDate(d.T),
 open: USDT\_BTC.O \* d.O,
 high: USDT\_BTC.H \* d.H,
 low: USDT\_BTC.L \* d.L,
 close: USDT\_BTC.C \* d.C,
 volume: d.V
 }
}

The step interval is a new config variable called tickInterval. You can go as low as five minutes or as long as several hours. I went with an hour as it’s more robust and I don’t want fast trading.

const configs = {
 cancelOpenOrdersOnStart: true ,
 maxHoursToHoldOrder: 0.5,
 refreshTimeout: 180000, // 3 minutes
 tickInterval: 'hour',
 markets: [
 'ADA',
 'BCC',
 'DASH'
 ]
}

Also not that I multiply the values with USDT_BTC. Bittrex always displays a BTC value. As I don’t want to trade on a given BTC instead on the actual USD value of the currency I have to calculate a bit.

You can skip the USDT_BTC part if you want to trade on raw BTC value curves.

Step 6.6: Crunch the numbers

It’s time to get our market indicators. But wait! You don’t have to calculate it by yourself. there’s a package for that. Install react stockcharts together with react and you got the math for free.

rrag/react-stockcharts

I want to use EMA. We also need a time and date parser.

import { timeParse } from'd3-time-format'
import { ema } from'react-stockcharts/lib/indicator'

const parseDate = timeParse('%Y-%m-%dT%H:%M:%S')

First let’s inject our market indicators.

async injectMarketIndicators (data) {
const start = now()

await Promise.map(data, async (d) =\> {
 d.keyFigures = await this.calculateMarketIndicators(d.candles)
 })

 log.info(`Calculated key figures ${(now() - start).toFixed(5)} ms`)
}

calculateMarketIndicators (data) {
const ema50 = ema()
 .id(0)
 .options({windowSize: 50})
 .merge((d, c) =\> {d.ema50 = c})
 .accessor(d =\> d.ema50)

const ema15 = ema()
 .id(1)
 .options({windowSize: 15})
 .merge((d, c) =\> {d.ema15 = c})
 .accessor(d =\> d.ema15)

return ema50(ema15(data))
}

The windowSize defines the timespan to calculate the indicators from.

Step 6.7: Count steps since last EMA crossing

As an EMA Crossing I define a point in time where my two defined EMA values (EMA50 and EMA15) crossed. Like a break even for cryptocurrencies.

async countEmaCrossPointTicks (data) {
const start = now()

await Promise.map(data, async (d) =\> {
const lastKeyFigures = d.keyFigures[d.keyFigures.length - 1]
const lastEmaDifference = lastKeyFigures.ema50 - lastKeyFigures.ema15

 d.positiveTicks = 0
 d.negativeTicks = 0
for ( let i = d.keyFigures.length - 1; i \> 0; i--) {
const keyFigures = d.keyFigures[i]

if (lastEmaDifference \> 0 && keyFigures.ema50 - keyFigures.ema15 \> 0) {
 d.negativeTicks++
 } else if (lastEmaDifference \< 0 && keyFigures.ema50 - keyFigures.ema15 \< 0) {
 d.positiveTicks++
 } else {
break  
}
 }
 })

 log.info(`Counted ticks since last ema crossing ${(now() - start).toFixed(5)} ms`)
}

Every currency now has either a positive or a negative step counter. This tells me how very good or very bad it would be to invest in this currency at this given point in time.

Step 6.8: Inject closed order history

In the past I made decisions on how much profit I made since I bought that coin. Or how much loss I gained since last buy order. Currently I don’t use that information.

async injectClosedOrderHistory (data) {
const start = now()

await Promise.map(data, async (d) =\> {
 d.orderHistory = await this.bittrex.getOrderHistory({
 market: `BTC-${d.MarketCurrency}`
 })
 }, {concurrency: 10})

 log.info(`Injected closed orders ${(now() - start).toFixed(5)} ms`)
}

Every currency now has a orderHistory array filled with old orders. Bittrex does sadly only serve orders from the last 30 days or 500 entries in total. So use that with caution.

Step 6.9: Refresh market history

As we calculate and crunch the numbers time has passed by and the latest currency value might wrong at this time. So we refresh it in the loop.

await this.injectMarketSummaries( this.currencies)

Step 6.10: Decide where to invest and what to sell

This will be the hardest part. When is it perfect to invest in a currency? When is it better to reject a current invest and start over? When do you do nothing and wait?

I decided to only look on my EMA crossings and how long the are now. That’s what my counted ticks are for. I also added a minimum tick counter value config variable to prevent invest hopping (buy, sell, buy, sell in a short time).

const configs = {
 cancelOpenOrdersOnStart: true ,
 maxEffectiveLoss: 60, // 60%
 maxHoursToHoldOrder: 0.5,
 refreshTimeout: 180000, // 3 minutes
 tickInterval: 'hour',
 markets: [
 'ADA',
 'BCC',
 'DASH'
 ],
 minimumEmaTicks: 5
}

I also introduced a maximum loss cap to reject invest that fall way to low.

async evaluateInvestHoldOrReject (data) {
const start = now()

await Promise.map(data, async (d) =\> {
const lastKeyFigures = d.keyFigures[d.keyFigures.length - 1]

 d.holdOrReject = INVEST\_HOLD\_OR\_REJECT.HOLD

if (d.balance && d.balance.Available \> 0) {
if (lastKeyFigures.ema15 \< lastKeyFigures.ema50 && d.negativeTicks \>= configs.minimumEmaTicks) {
 log.info(`Will reject ${d.MarketCurrency} due to ${d.negativeTicks} negative ema ticks`)
 d.holdOrReject = INVEST\_HOLD\_OR\_REJECT.REJECT
 } else if (d.balance.Available \* d.marketSummary.Bid \< configs.btcPerInvest \* (1 - configs.maxEffectiveLoss / 100)) {
 log.info(`Will reject ${d.MarketCurrency} due to falling below ${configs.btcPerInvest} btc`)
 d.holdOrReject = INVEST\_HOLD\_OR\_REJECT.REJECT
 }
 } else if (!d.balance || (d.balance && d.balance.Available === 0)) {
if (lastKeyFigures.ema15 \> lastKeyFigures.ema50 && d.positiveTicks \>= configs.minimumEmaTicks) {
 log.info(`Will invest in ${d.MarketCurrency} due to ${d.positiveTicks} positive ema ticks. EMA15 ${lastKeyFigures.ema15} \> EMA50 ${lastKeyFigures.ema50}`)
 d.holdOrReject = INVEST\_HOLD\_OR\_REJECT.INVEST
 }
 }
 })
 log.info(`Evaluated invest hold or reject ${(now() - start).toFixed(5)} ms`)
}

Step 6.11: Reject bad investments

As you evaluated investments as bad they will be sold. So let’s do so.

async rejectBadInvestments (data) {
const start = now()

await Promise.map(data, async (d) =\> {
if (d.holdOrReject === INVEST\_HOLD\_OR\_REJECT.REJECT) {
if (d.marketSummary.Bid \* d.balance.Available \>= configs.minimumSellBalanceInBTC && d.balance.Available \> d.MinTradeSize) {
try {
await this.bittrex.sellLimit({
 market: `${d.BaseCurrency}-${d.MarketCurrency}`,
 quantity: d.balance.Available,
 rate: (d.marketSummary.Bid - configs.rateSellBuyExtraBtc)
 })
 } catch (e) {
 log.info(e)
 }
 log.info(`${d.MarketCurrency} placed REJECT SELL order`)
 }
 }
 }, {concurrency: 20})
 log.info(`Rejected investments ${(now() - start).toFixed(5)} ms`)
}

I added configs.rateSellBuyExtraBtc to add a tiny amount of BTC to secure the sell and buy order. Also configs.minimumSellBalanceInBTC was added to check the bittrex sell threshold. Bittrex doesn’t allow orders smaller than that.

const configs = {
 cancelOpenOrdersOnStart: true ,
 minimumSellBalanceInBTC: 0.0005,
 maxEffectiveLoss: 60, // 60%
 maxHoursToHoldOrder: 0.5,
 refreshTimeout: 180000, // 3 minutes
 rateSellBuyExtraBtc: 0.0000000000001, // to secure buy or sell
 tickInterval: 'hour',
 markets: [
 'ADA',
 'BCC',
 'DASH'
 ],
 minimumEmaTicks: 3
}

Step 6.12: Invest all the bitcoin!

Now let’s throw all our remaining bitcoin value into currencies that seems worth it. I sorted my options by EMA ticks to invest in fresh risers first.

I also instroduced two new config variables.

const configs = {
 btcBuffer: 0.01, // btc that has to stay on the bank
 btcPerInvest: 0.005,
 cancelOpenOrdersOnStart: true ,
 minimumSellBalanceInBTC: 0.0005,
 maxEffectiveLoss: 60, // 60%
 maxHoursToHoldOrder: 0.5,
 refreshTimeout: 180000, // 3 minutes
 rateSellBuyExtraBtc: 0.0000000000001, // to secure buy or sell
 tickInterval: 'hour',
 markets: [
 'ADA',
 'BCC',
 'DASH'
 ],
 minimumEmaTicks: 3
}

btcPerInvest defines a fixed BTC value which will be used to make that order happen. You can also scale that value exponential based on your available bitcoin.
btcBuffer defines a fixed btc value which has to stay and will not used for investment. I like to have some btc left for my manual trades.

async invest (data) {
const start = now()

let buyCounter = 0

 // Sort by tick count from last ema crossing
 data.sort((a, b) =\> a.positiveTicks - b.positiveTicks)
for ( let d of data) {
if ( this.bitcoin.Available \> configs.btcPerInvest + configs.btcBuffer) {
if (d.holdOrReject === INVEST\_HOLD\_OR\_REJECT.INVEST) {
const quantity = (configs.btcPerInvest - 0.00000623) / d.marketSummary.Ask

if (quantity \> d.MinTradeSize) {
try {
await this.bittrex.buyLimit({
 market: `${d.BaseCurrency}-${d.MarketCurrency}`,
 quantity,
 rate: (d.marketSummary.Ask + configs.rateSellBuyExtraBtc)
 })
 buyCounter++
this.bitcoin.Available -= configs.btcPerInvest
 log.info(`Invested ${configs.btcPerInvest} bitcoin in ${d.MarketCurrency} for ${quantity} amount`)
 } catch (e) {
 log.info(e)
 }
 }
 }
 } else {
 log.info(`Not enough btc left to invest. Keep saving more!`)
break  
}
 }

 log.info(`Invested ${configs.btcPerInvest * buyCounter} btc in ${buyCounter} options ${(now() - start).toFixed(5)} ms`)
}

Step 7: Deploy

The bot is done. I push the code onto my server and start it with

$ docker-compose up --build -d

This will build and start my bot. Logs can be viewed via logs of docker-compose.

Step 8: Improve your bot

Your bot will make errors, you will make bad invest decisions based on certain market indicators. Learn from it and improve your code. To be hones, my bot lost nearly half my money before becoming stable and making actual profit again. Don’t give up.

Structure your react apps the mantra way

Sascha Becker — Mon, 18 Sep 2017 13:53:14 +0000

The holy grail of discussion is what is the best way to structure your project. The answer is, there is none. But here is one I fell in love with.

Then mantra way!

First of let’s talk about what makes a structure good. There are certain elements that make good use of organisation.

Easy to navigate
Scales well over time
Swap logic is fast and without many breaks

So what exactly is mantra? I’m not talking about meditate while creating folders. It’s the mantra js spec application architecture developed by kadira back when meteor js was the cool kid.

It described an architecture that should be maintainable and future proof. They claimed once set up it will satisfy your inner geek for up to five years. Not even kadira lasted that long by the way, nor will maybe meteor.

So I moved on, turned my back from meteor and dived into the raw package land. And mantra js was the one thing that I loved and tried to embed.

Let’s take a look of what a project could look like. Here is an example of a website with multiple routes, components, actions and reducers.

Stay with me. It’s not that confusing as it seems.

Modules

Let’s break it down and we start with the modules folder. It’s the core idea of mantra and what makes it so great in my opinion.

Modules is business concern first. That means I don’t split it into

components
containers
reducers
actions

right here. Instead mantra adds a layer on top to achieve better maintainability and hopefully makes this future proof.

One important rule is that you don’t cascade modules. If a module should have a submodule create it separately. The advantage is that you see all modules at a glance. You don’t have to open every module to see what’s inside.

Module content

But what’s inside a module?

Components folder holds every dumb component you need in that module and that module alone. Separation of concern is key here. You can read more about here.

**import** React, { Component } **from**'react'
**import** Text **from**'../../core/components/Text'
**import** \* **as** colors **from**'material-ui/styles/colors'
**import** GameTile **from**'./GameTile'

**export default class** Games **extends** Component {
 render () {
**const** {
 mobile
 } = **this**.props

**return** (
 \<div\>
 some content
 \</div\>
 )
 }
}

Containers folder holds the logic. What should be pushed into my dumb components? What data should be fetched (via dispatching actions or redux state)? All those concerns should be stored in here.

**import** React, { Component } **from**'react'
**import** { connect } **from**'react-redux'
**import** Games **from**'../components/Games'
**import** { actions **as** coreActions } **from**'../../core'

**class** Container **extends** Component {
 componentDidMount () {
**this**.props.dispatch(coreActions.setMenuIndex(1))
 }

render () {
**return** (
 \<Games
 {... **this**.props}
 /\>
 )
 }
}

**export default** connect((state) =\> {
**return** {
 mobile: state.core.responsive.mobile
 }
})(Container)

As you can see I introduced a “core module” to make shared actions happen. In some point of time you can’t isolate modules completely. Some actions have to be shared and I think that’s a good compromise.

Routes folder holds, as the name suggests, all the routes that belong to that module. In this case we have a “/games” route that needs to be hooked to the games container.

**import** React **from**'react'
**import** { Route } **from**'react-router-dom'
**import** Games **from**'../containers/Games'

**export default** (store) =\> {
**return** (
 \<Route exact path='/games' component={Games}/\>
 )
}

Additional routes for example “/games/:id” are also welcome here.

Additional folders

Actions and reducers also need a place to live.

Actions folder holds the action types for redux calls.

**export const** MENU\_TOGGLE = 'MENU\_TOGGLE'
**export const** SET\_RESPONSIVE\_BREAKPOINT = 'SET\_RESPONSIVE\_BREAKPOINT'
**export const** SET\_MENU\_INDEX = 'SET\_MENU\_INDEX'

And the actual actions which can be dispatched.

**import** \* **as** TYPES **from**'./actionTypes'

**export function** toggleMenu (open) {
**return** {type: TYPES.MENU\_TOGGLE, open}
}
**export function** setResponsiveBreakpoint (value) {
**return** {type: TYPES.SET\_RESPONSIVE\_BREAKPOINT, value}
}
**export function** setMenuIndex (index) {
**return** {type: TYPES.SET\_MENU\_INDEX, index}
}

Reducers folder holds obviously the reducers for that module.

**import** \* **as** TYPES **from**'../actions/actionTypes'

**const** defaultState = {
 menu: {
 open: **false** ,
 index: -1
 },
 mobileView: **true** ,
 responsive: {
 mobile: **false** ,
 tablet: **false** ,
 desktop: **true**  
}
}

**function** toggleMenu (state, action) {
**return** {
 ...state,
 menu: {
 ...state.menu,
 open: **typeof** action.open === 'undefined' ? !state.menu.open : action.open
 }
 }
}

**function** setMenuIndex (state, action) {
**return** {
 ...state,
 menu: {
 ...state.menu,
 index: action.index
 }
 }
}

**function** setResponsiveBreakpoint (state, action) {
**return** {
 ...state,
 responsive: {
 mobile: action.value \<= 768,
 tablet: action.value \> 768 && action.value \<= 1200,
 desktop: action.value \> 1200
 }
 }
}

**export default function** (state = defaultState, action) {
**switch** (action.type) {
**case** TYPES.MENU\_TOGGLE:
**return** toggleMenu(state, action)
**case** TYPES.SET\_RESPONSIVE\_BREAKPOINT:
**return** setResponsiveBreakpoint(state, action)
**case** TYPES.SET\_MENU\_INDEX:
**return** setMenuIndex(state, action)
**default** :
**return** state
 }
}

You can also split this into multiple files if you want.

And now comes the important part, the glue! After you defined your folders with its logic and visual components you want to expose it, right? That’s where the index.js of the module folder comes in. It collects all the needed parts of the module and expose it for further use. Something like this:

**import** \* **as** actions **from**'./actions'
**import** reducers **from**'./reducers'
**import** routes **from**'./routes'

**export** {
 actions,
 reducers,
 routes
}

So everytime you need access to this module you have all the important parts right in the root of the module folder.

Make it run

So now comes the fun part. After defining our modules we need to deploy them within our application. Let’s take a look back to our overview:

First let’s combine all the reducers. In “src/reducers/index.js” we bundle all the reducers exposed by our modules.

**export** { reducer as core } **from**'../modules/core'
**export** { reducer as games } **from**'../modules/games'
**export** { reducer as anotherModule } **from**'../modules/anotherModule'

This can be later used to combine our store just with:

**import** \* **as** reducers **from**'../reducers'

And all our reducers from all defined modules are ready to go. Neat!

Same goes for the routes. Take a look inside the AppRoutes.js content:

**import** React **from**'react'
**import** { Switch } **from**'react-router-dom'

**import** Application **from**'./modules/core/containers/Application'
**import** { routes **as** home } **from**'./modules/home'
**import** { routes **as** games } **from**'./modules/games'
**import** { routes **as** team } **from**'./modules/team'
**import** { routes **as** contact } **from**'./modules/contact'
**import** { routes **as** impressum } **from**'./modules/impressum'

**export default** (store) =\> {
**return** (
 \<Switch\>
 \<Application\>
 {home(store)}
 {games(store)}
 {team(store)}
 {contact(store)}
 {impressum(store)}
 \</Application\>
 \</Switch\>
 )
}

This file just exposed all routes defined in our modules. They are embedded in an shared Application component defined in the core module. Application is the wrapper with header and footer and takes children as prop.

Now just import those routes in your Root.js and everything is ready to deploy.

**import** React **from**'react'
**import** { Provider } **from**'react-redux'
**import** \* **as** OfflinePluginRuntime **from**'offline-plugin/runtime'

**import** configureStore **from**'./configs/configureStore'
**import** createRoutes **from**'./AppRoutes'

**import** createHistory **from**'history/createBrowserHistory'
**import** { ConnectedRouter } **from**'react-router-redux'

**import** MuiThemeProvider **from**'material-ui/styles/MuiThemeProvider'
**import** getMuiTheme **from**'material-ui/styles/getMuiTheme'
**import** theme **from**'./theme'

**import**'./main.less'

**const** history = createHistory()

**const** store = configureStore({}, history)

OfflinePluginRuntime.install()

**export default** () =\> (
 \<Provider store={store}\>
 \<MuiThemeProvider muiTheme={getMuiTheme(theme)}\>
 \<ConnectedRouter history={history}\>
 {createRoutes(store)}
 \</ConnectedRouter\>
 \</MuiThemeProvider\>
 \</Provider\>
)

Conclusion

We now have several modules that are isolated from each other. That makes them easy to swap out for others. Also import statements are now extremely short. Further changes inside a module make distraction while coding from another module obsolete. Maintainability is far better than searching for files associated with a specific concern. It scales well due to just a few glue points needed and less clutter inside the modules folder.

Supplement

I wrote a npm package to hide most of the preparations needed to use this structure and do most of this behind the curtain.

TeamWertarbyte/module-loader

It’s still in an early stage an every PR and comment is welcome. But I already use this in production so I’m pretty confident that this will work as intended.