While my days of playing DOTA2 are over. I do remember those games where everyone picked mid or carry and the team just doesn’t have a damn courier or any support players and it makes it very unbearable for the team to play.

Games aside, real life can feel like this for many people. I returned to Hong Kong for the Chinese New Year and noticed the negativity in people’s emotions and actions at a all-time high. People just don’t want to support each other and it’s sad.

We all know helping each other is tough but imagine a world where no one helped anyone. Where it’s every man and woman for themselves. …

Before we begin I should mention that the version of Phoenix I’m running this tutorial on is 1.4.8 which is the latest version at the time of writing.

You can configure Phoenix to connect to which ever databases you like, there files are located in the config :

use Mix.Config# Configure your database
config :app, App.Repo,
  database: "app_development",
  hostname: "localhost",
  show_sensitive_data_on_connection_error: true,
  pool_size: 10

This is useful if you wish to connect to an application’s database on which you’re rewriting.

Getting into the rails console equivalent:

In your project directory you can type: iex -S mix .

In our examples we’ll use App to refer to the name of your Phoenix project application module name. Ecto has solid documentation on writing queries. But to get started here’s a simple…

I’m learning Phoenix and Semantic UI simultaneously and wanted to kick off a new project that has both of them in the mix.

I’m going to assume in this guide that you’ve created a Phoenix project and have Elixir and Phoenix installed — if not follow the official guide here: https://hexdocs.pm/phoenix/installation.html#content.

According to the changelog — the Phoenix application generator officially switched from Brunch to Webpack in 1.4.0 which is fairly recent. So when you create a new application using mix phx.new — it creates an assets directory containing a package.json …

You’ve hit the stage where the code base is too complex and now you need to refactor. You want to catch the parts you didn’t test and you want to ensure that everything you move and change has coverage.

Luckily this is really easy with Jest, in our case we’re using Jest in conjunction with React and Enzyme but the setup should be the same for any environment whether you’re doing Angular, Ember, Vue, or even just Node or VanillaJS.

In your package.json file, add this test:coverage command to your scripts:

..."scripts": {
  ...
  "test:coverage": "react-scripts test --coverage --findRelatedTests ./src/**"
  ...
},...

You can run it with npm run test:coverage

After that you can open coverage/lcov-report/index.html and it’ll open something like this in your browser:

I understand keeping things DRY (don’t repeat yourself); what I don’t understand is verbosely using shared examples within shared examples.

Here are the key reasons:

· It makes it hard to adjust your specs to match business requirements — suddenly as a developer you need to not only remember how to change it programmatically; but now you have to remember which shared example to use — and to trust it does what it says.

· Then there’s the issue that it makes debugging a lot more complicated. Want to simply add a binding.pry/debugger to a step in your test? …

For over a month now I’ve been coaching and mentoring Nat and Saran Davaa who started this project with zero programming experience; I’m writing this to share with you how I approached it and why it was so successful.

Saran Davaa approached me at a Dharma talk in San Francisco with her game idea for Trace, a clear 10 slide pitch deck for a simple board game idea basically describing the game mechanics. I didn’t judge the idea either, I simply said, “I’d help her make it.”

Then I remembered another student, Nat, who bumped into me a while back saying she also wanted to learn programming. I reached out to her — told her about the idea and the team was formed. …