1 min read

1. Remove Bootstrap

$ echo "" > assets/css/phoenix.css

2. Install Bulma

$ cd assets
$ npm install --save bulma

3. Install sass-brunch

$ npm install --save-dev sass-brunch

4. Add sass-brunch config to brunch

plugins: {
  sass: {
    options: {
      includePaths: ['node_modules/bulma']
    },

And the scss folder to the watch pass.

paths: {
    // Dependencies and current project directories to watch
    watched: ["static", "css", "scss", "js", "vendor"],
    ...
  },
...

5. Rename app.css to app.scss

$ cd assets/css; mv app.css app.scss

6. Import Bulma in app.scss

@import "bulma";

(Optional:)

7. Create your own theme

$ mkdir assets/scss
$ touch assets/scss/custom.scss

8. Import initial variables in custom.scss

@import "../node_modules/bulma/sass/utilities/initial-variables";
$primary: $red

9. Import custom.scss in app.scss

@import "../scss/custom";

kaputse

#piratebox on 5A (solar) battery

Got ~16-18h runtime out of it. Not to bad.

kaputse

Non-OTP dependencies in (distillery) release

1 min read

Adding Erlang libraries to your Elixir project and having them included in your (Distillery based) release should work the same way as adding any Elixir library. But sometimes you stumble upon a library that does not implement the OTP application behaviour - thus it can not be added to the applications key - and is not automatically detected by Distillery as a runtime dependency.

Frankly I do not know the exact reason for that but digging through the source and documentation I found a way to solve this problem for my case. You need to specify your library with the :load option in your release configuration (rel/config.exs).

release :myapp do
  set version: "0.1.0"
  set applications: [:app_a, :app_b, some_dep: :load]
end>

This defines some_dep as runtime dependency but not being started (OTP).

Hope this saves you some time. =)

kaputse

No love for SOAP

1 min read

So I had to do some SOAPy work this week and since it is some pre-war tech I had to dive in again. Here is the essence of what I got (from other ppl) :)

Well, SOAP isn't a "modern" specification, so it's only (somewhat) well supported by the technology stacks that were mainstream when the big vendors were pushing WS-Deathstar (Java, .NET) - so all that technology is already in place. (via)

Ohh death star you say? That gives me ...

I have PTSD from my experience with SOAP/WSDL. I'm even having problems typing these words. [...] (via)

No, it could not be that hard. No. Let's ask s/o who actually has build a library around this death star:

Detergent helps make SOAP interactions in Erlang uhh... cleaner (pun totally intended)! (via)

kaputse

Sainsmart 1.8 display + Rasperry Pi

1 min read

Recently I bougt one of those tiny Sainsmart 1.8 inch displays to use it as a secondary monitor for my Kodi-based (raspian) media center in the living room.

The setup was pretty easy and fbi showed up pictures on the display five minutes after I got the wiring done. \o/

The problems started when I tried to run some demo pygame code on it. All I got was an error I did not understand because everything was setup correctly.

Traceback (most recent call last):
  File "test.py", line 19, in 
    pygame.display.set_mode()
pygame.error: No video mode large enough for 128x160

After fiddling around for a while, I created the file /etc/fbmodes with the following content:

mode "128×160"
geometry 128 160 128 160 16
timings 0 0 0 0 0 0 0
endmode

Works for me. Errors gone. =)

kaputse

Plug love

1 min read

So I just finished Ch. 5 "Authenticating Users" in the Programming Phoenix book and after coding along the examples of ten pages, on the last page of this chapter I was like "Wait a sec, where do they persist the session data?!" and then I discovered this gem: https://hexdocs.pm/plug/Plug.Session.COOKIE.html

#elixir #phoenix #plug #fp #stack16