Byteplumbing

Smooth progress indicator with CSS

Sat, 16 Mar 2024 13:24:00 +0300

Recently I worked on upload button feature using ActiveStorage::DirectUpload features of the Ruby on Rails web framework. There’s nothing too fancy here, but I got fascinated how nice it was to implement upload progress bar with the help of modern CSS features.

Key features to implement it were:

CSS variables and their manipulation from Javascript implementation to reflect progress to the styles
CSS transitions for smooth animation

Simple generic example

Full example is available in Codepen, but let’s go through the code in smaller steps.

Smoothly animated progress bar using CSS variables and transitions.

1. Basic custom button styling

We start with just the <button> element and custom class for it.

<button class="upload-button">
  Upload file
</button>

And some custom styling with CSS variable based design tokens.

:root {
  --primary-color: #0af;
  --button-border-width: 2px;
  --button-border-radius: 0.5em;
  --button-padding: 8px;
}

button {
  padding: var(--button-padding);
  background-color: inherit;
  border: var(--button-border-width) solid var(--primary-color);
  border-radius: var(--button-border-radius);
}

2. Progress indicator positioning

Progress indicator is created as ::after pseudoelement, but first we define upload button component’s positioning to relative to be able to anchor pseudoelement absolute positioning in relation to the main button component. If we wouldn’t do this absolute positioning would be done in relation to the closest parent DOM element with position other than the default static or if none are found the main document itself.

.upload-button {
  position: relative;
}

Then we create pseudoelement by assigning content to it and position it to the bottom part of the button taking about 75% of the empty padding area there. CSS calc() function is a handy helper to calculate height and top position based on the variables used to style button element.

.upload-button::after {
  content: " ";
  position: absolute;
  height: calc(var(--button-padding) / 1.5);
  left: 0;
  top: calc(100% - (var(--button-padding)) / 1.5);
  background-color: var(--primary-color);
  border-radius: var(--button-border-radius);
}

3. Updating progress

Progress is visualized as ::after element width from 0% to 100%. This is done using CSS variable which is updated from JS callback.

First variable is initialized and used to define element width:

:root {
  --upload-progress: 0%;
}

.upload-button::after {
  width: var(--upload-progress);
}

In the Javascript side we should have some kind of event or callback mechanism which would provide information about progress. In the Codepen version there’s mock class, which provides completion percentage to the callback:

const button = document.querySelector(".upload-button");

function progressCallback(newProgress) {
  button.style.setProperty("--upload-progress", `${newProgress.toFixed(2)}%`);
}

4. Smoother transition

At this point progress bar movement is a bit jerky, but it can be smoothened using CSS transition.

.upload-button::after {
  transition: width 200ms ease-out;
}

5. Estimate finishing time to get smoothest animation

Define transition delay using CSS variable
Record start timestamp
Use progress value and current time to estimate total upload time
Update CSS transition delay based on the total time

:root {
  --upload-progress: 0%;
  --upload-transition-delay: 200ms;
}

.upload-button::after {
  width: var(--upload-progress);
  transition: width var(--upload-transition-delay) ease-out;
}

function progressCallback(newProgress) {
  const spent = Date.now() - start;
  const total = Math.round(spent / (newProgress / 100));
  button.style.setProperty("--upload-progress", `${newProgress.toFixed(2)}%`);
  button.style.setProperty("--upload-transition-delay", `${total}ms`);
}

ActiveStorage integration

Using this approach with ActiveStorage is really straightforward and documented extensively at the Rails guides. In the nutshell:

Create custom Uploader class which wraps the DirectUpload imported from @rails/activestorage NPM library
Get DOM element reference for the element you use to indicate progress ie. .upload-button in the above examples ready before starting upload to avoid unnecessary DOM queries
Record start timestamp as uploader property
Use directUploadDidProgress(event) { ... } callback to update CSS variables --upload-progress and --upload-transition-delay

directUploadDidProgress(event) {
  const ratio = (event.loaded / event.total);
  const spent = Date.now() - this.start;
  const total = Math.round(spent / ratio);
  const percentage = (100 * ratio).toFixed(2);
  button.style.setProperty("--upload-progress", `${percentage}%`);
  button.style.setProperty("--upload-transition-delay", `${total}ms`);
}

Why use variables instead of manipulating styles directly?

CSS variables provides means to separate concerns. This JS handles interactivity and CSS the visual presentation in the same place.
Pseudoelements can’t be accessed through JS DOM queries. CSS variables provides a way to provide information affecting pseudoelements. Using pseudoelement instead of creating additional DOM elements enables us to have more semantic DOM without non-content visual presentation elements.

Better performance with Hugo Pipes

Sun, 03 Oct 2021 18:31:10 +0300

I recently used Hugo Pipes to optimize asset handling in this site and replaced old Webpack based hack I had used to achieve same.

That hack was done in the times of Hugo version 0.3x. Currently all necessary things like JS bundling, CSS pre- and post-processing, fingerprinting, minification, etc is possible with Hugo native features:

Markdown render hooks for customizing how certain blocks in Markdown content is rendered
Hugo Pipes for CSS / JS processing, bundling, fingerprinting, minification, image processing etc
Page bundles for better organization of post related resources with Markdown content

Like you see in following snippets, Hugo Pipes version is really simple to use and maintain compared to configuring and handling Webpack builds. Essentially they work like you would expect with zero configuration.

Styles

Handling CSS is really simple:

{{ $style := resources.Get "stylesheets/all.css.scss" | toCSS | minify | fingerprint }}
<link rel="stylesheet"
  href="{{ $style.Permalink }}"
  integrity="{{ $style.Data.Integrity }}" />

Referenced CSS file could be stored in global /assets directory, or in the themes/{{ theme name}}/assets.

In the above template function toCSS and minify does exactly what it says in the tin, but fingerprint is a bit more special enabling multiple things with the content based hash it creates:

It determines actual filename generated for the asset stored in the public directory after the build. .Permalink and .RelPermalink provides urls with that hash fingerprint enabling cache busting when content changes.
It also calculates hash value which could be used as subresources integrity hash

Javascript

Bundling Javascript is just as easy as CSS above and template functions are used in similar fashion.

{{ $jsMain := resources.Get "javascripts/index.js" | js.Build "main.js" | minify | fingerprint }}
<script type="application/javascript"
  src="{{ $jsMain.Permalink }}"
  integrity="{{ $jsMain.Data.Integrity }}">
</script>

It uses esbuild under the hood and NPM dependencies installed from package.json with NPM or Yarn works just like one would expect.

Images

Image handling needed a bit more work, but it’s also great example how powerful content rendering possibilities Hugo has.

Stuff I had to do:

Store images in /assets/images directory, similar directory inside theme, or with the page bundle directory
Create image rendering hook to customize how regular Markdown image references eg. ![alt text](file path / name) are rendered.
Customize templates to use global resources or .Page.Resources modules

Here’s the layouts/_default/_markup/render-image.html implementation:

{{ $image := .Page.Resources.GetMatch (printf "%s" (.Destination | safeURL)) | fingerprint }}
{{ $alt := .PlainText | safeHTML }}
{{ $caption := "" }}
{{ with .Title }}
  {{ $caption = . | safeHTML }}
{{ end }}
<figure>
  <a href="{{ $image.RelPermalink }}">
    <img
      src="{{ $image.RelPermalink }}"
      width="{{ $image.Width }}"
      height="{{ $image.Height }}"
      alt="{{ if $alt }}{{ $alt }}{{ else if $caption }}{{ $caption | markdownify | plainify }}{{ else }}&nbsp;{{ end }}"
      />
  </a>
  {{ with $caption }}
    <figcaption>{{ . | markdownify }}</figcaption>
  {{ end }}
</figure>

And another example how global images could be used in the layouts:

<div class="logo">
  <a href="/" title="Home">
    {{ with resources.Get "images/logo.jpg" }}
      {{ $image := . | fingerprint }}
      <img
        src="{{ $image.RelPermalink }}"
        width="{{ $image.Width }}"
        height="{{ $image.Height }}"
        alt="Logo"
        />
    {{ end }}
  </a>
</div>

I’m especially happy to be able to use regular Markdown for all images instead of custom shortcodes I earlies had to implement for that Webpack + manifest json version.

CloudWatch custom metrics with Rails

Thu, 24 Jan 2019 19:06:57 +0200

I recently had to implement Rails application monitoring using CloudWatch in a work project. App in question had multiple integrations to other REST services so it made sense to be able track their response times, error status counts etc to better debug performance anomalies.

Here’s steps how I used Active Support Instrumentation API of Rails to feed those as custom CloudWatch metrics.

Building blocks

Rails Instrumentation API

Instrumentation API is a part of Rails core in Active Support and it implements publish-subscribe pattern for providing information about app behavior, when certain events started and finished. Rails has number of internal events described in Rails guides, and eg. logging SQL query times, or AcionView render times is based on this feature.

Instrumentation API could be extended with custom events, so it would make perfect sense to use track request times to 3rd party APIs.

HTTP client middleware

Faraday is my go to HTTP library when implementing API clients in Ruby. I like its architecture and way of using middlewares to extend and re-use logic. Official faraday_middleware gem also includes Instrumentation middleware to plug Faraday connection to ActiveSupport::Notifications.

CloudWatch

We are hosting the app I was working with at the AWS and had CloudWatch dashboard set up to monitor Fargate resource usage, RDS connections, ElastiCache hits & misses etc, so it would be nice to include something to infer 3rd party API health from same dashboard.

That’s possible using custom metrics, and they are pretty convenient to upload using official Ruby SDK for CloudWatch.

However keep in mind that CloudWatch pricing is based on the number of dashboards, metrics, request counts etc so the cost definitely will increase when you add more features using it.

Steps

1. Install gems

Install necessary gems, by including following in your Gemfile:

gem "faraday"
gem "faraday_middleware"
gem "aws-sdk-cloudwatch", require: false

2. Plug Faraday based client to Instrumentation API

I usually have some place where default connection for the custom client library is instantiated and necessary middlewares are included. For example it could be something like:

def client_connection
  Faraday.new do
    faraday.use Faraday::Response::RaiseError
    faraday.use :instrumentation, name: "request.example_api"
    faraday.response :json
    faraday.adapter Faraday.default_adapter
  end
end

Name option given to middleware could be anything what makes sense in your application domain, and it is the name which is used to subscribe for these instrumentation events. Here we used request.example_api. If name is omitted default request.faraday is used.

3. Feed metrics to CloudWatch

For now I’ve been using simple initializer to hook into events. So I have following at config/initializers/example_api_metrics.rb:

require "aws-sdk-cloudwatch"

def put_request_metrics(name, starts, ends, env)
  duration = ends - starts
  timestamp = Time.now.utc

  # Derive status code category to be used as metric name for request
  # counts enabling us to track number of interesting results.
  status_metric = begin
                    if env[:status] >= 200 && env[:status] < 300
                      "Status2XX"
                    elsif env[:status] >= 400 && env[:status] < 500
                      "Status4XX"
                    elsif env[:status] >= 500 && env[:status] < 600
                      "Status5XX"
                    else
                      "StatusOther"
                    end
                  end

  client = Aws::CloudWatch::Client.new
  client.put_metric_data(
    namespace: "ExampleApi",
    metric_data: [
      {
        metric_name: "ResponseTime",
        dimensions: [{
          name: "Environment",
          value: Rails.env.to_s
        }],
        timestamp: timestamp,
        value: duration,
        unit: "Seconds"
      }, {
        metric_name: status_metric,
        dimensions: [{
          name: "Environment",
          value: Rails.env.to_s
        }],
        timestamp: timestamp,
        value: 1,
        unit: "Count"
      }
    ]
  )
end

ActiveSupport::Notifications
  .subscribe("request.example_api") do |name, starts, ends, _, env|
    put_request_metrics name, starts, ends, env
end

In above example dimensions is completely optional but it allows adding extra information to recorded values making it easier for example to tell apart multiple environments sharing same AWS account.

Notice that Aws::CloudWatch::Client.new is called without any additional parameters. This way it will try to retrieve AWS credentials and region info from environment variables, instance profiles or task execution roles. Of course you could include them as arguments too if you prefer Rails 5 encrypted credentials instead.

Inspecting Docker container network traffic

Sat, 13 Jan 2018 11:06:57 +0200

When developing dockerized services with other communication end-points than browser client one soon needs some ways to capture and debug network traffic from containers. Here’s some tools and tips I’ve been using.

Capturing traffic

Docker uses network bridge for all traffic, and by default containers will be using bridge named docker0. However if you are using docker-compose, which by default creates own bridge for each configuration or you have other ways to configure docker networking the bridge you would like to capture would be different.

Use docker network ls command to list available Docker networks with the help of bridge link and ip addr show to find correct interface for your use case. Rest of this post will be using default docker0.

Docker Documentation for container networking has more details, and information for custom configurations.

Using tcpdump

Tcpdump is versatile commandline tool for capturing and analyzing network traffic. Try following to listen your containers:

tcpdump -i docker0

Or record traffic to a file:

tcpdump -i docker0 -w packets.cap

You could also use Wireshark which is GUI tool for analyzing traffic, and it could be also used to view output from tcpdump.

There’s still one problem though. Any sane service handling personal data should encrypt its communication preventing debuggin with simple packet capturing. To view encrypted TLS traffic we would need Man-in-the-middle transparently decryptin and re-encrypting traffic.

Setting up transparent HTTP(S) proxy

For man-in-the-middle setup we need following:

Proxy
IP packet forwarding to redirect traffic to proxy
Configure CA certificates from proxy as trusted by the service we are examining

Mitmproxy is a perfect tool for this job.

Packet forwarding and Mitmproxy setup

See Mitmproxy documentation for installation options or run it using official Docker images
Enable packet forwarding in your host system with sysctl:
```
sysctl -w net.ipv4.ip_forward=1
```
Use iptables to forward interesting traffic from bridge to proxy. Following will forward HTTP targeting default port 80 and HTTPS to default port 443 to proxy running in 8080 which is Mitmproxy default.
```
iptables -t nat -A PREROUTING -i docker0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i docker0 -p tcp --dport 443 -j REDIRECT --to-port 8080
```
Run mitmproxy in transparent mode:
```
mitmproxy -T --host
```

Configure CA certificates

Now HTTPS clients configured to verify server certificates would fail connecting, which will look like following in then Mitmproxy event log:

Mitmproxy generates its CA to directory $HOME/.mitmproxy, which could be mounted as a volume to your Docker container. If your are using Docker to run Mitmproxy you would mount volumes from that container.

docker run --volume $HOME/.mitmproxy:/usr/share/ca-certificates/custom some-image

Rest depends on used Linux distribution and service implementation you are targeting:

For Unix system tools in Alpine Linux based containers:
1. Mount custom certificates under some dir eg. custom at /usr/share/ca-certificates
```
docker run -v ~/.mitmproxy:/usr/share/ca-certificates/custom ...
```
2. Add custom/mitmproxy-ca-cert.pem to /etc/ca-certificates.conf in your container
```
echo custom/mitmproxy-ca-cert.pem >> /etc/ca-certificates.conf
```
3. Update trusted root certificates by running:
```
update-ca-certificates
```

NodeJS has support for NODE_EXTRA_CA_CERTS environment variable since v7.3.0

docker run --volume $HOME/.mitmproxy:/opt/extra-ca \
  -e NODE_EXTRA_CA_CERTS=/opt/extra-ca/mitmproxy-ca-cert.pem nodejs

Ruby OpenSSL uses system root certs or they could be overriden with SSL_CERT_FILE and SSL_CERT_DIR environment variables
For example Go, Elixir, Python based implementations would use system root certificates

After these steps it is possible to examine TLS traffic.

Extra tricks with mitmproxy

Possibilities with Mitmproxy are not limited to just inspection. For example see official documentation for how to edit request or response before letting it go through proxy to client or server.

Static asset cache busting for Hugo

Thu, 10 Aug 2017 21:31:10 +0300

Update since writing this post, Hugo has implemented number of great features providing native way to implement cache busting etc without Webpack.

Checkout new post: Better performance with Hugo Pipes.

Hugo is a blazing fast static site generator with a great architecture for managing content. However asset pipeline à la Middleman or Jekyll is something I have been missing especially for generating images with cache busting hashes in the filenames.

I solved that by configuring Webpack for something similar.

For starters: “Predictable long term caching with Webpack” was great help in getting base webpack config right and content hashes consistent between the builds. I recommend that you too check that out to get around a few Webpack quirks.

Webpack generated files needs to be available for Hugo as static site data and their final filenames including content hashes for cache busting has to be known during Hugo build step. That would be possible by using webpack-manifest-plugin to generate manifest.json which would be used as Hugo site data. Manifest configuration and different content use cases are described below.

Webpack config with bundle manifest

I have chosen to place original scripts, styles and images are under assets/javascripts, assets/stylesheets and assets/images directories.
Webpack is configured to generate its output into /static
Webpack-manifest-plugin generates JSON file containing single object with original filenames as keys and generated names as values. For example:
```
{
  "example.js": "example.c0ffee.js",
  "images/logo.svg": "media/logo.deadbeef.svg"
}
```
Webpack plugin configuration outputs manifest.json under /data directory in Hugo project.

Full configuration is following:

I have configured following npm scripts for Webpack usage during development and build time.

{
  "scripts": {
    "watch": "webpack --watch -d --progress --color",
    "build": "webpack --bail -p"
  }
}

When developing I run both yarn run watch and hugo server -D. In build job yarn run build is executed before Hugo.

Handling scripts and styles in Hugo templates

Using manifest.json to include correct styles and scripts…

When including CSS and Javascripts into Hugo templates actual filenames are read from Site data in following manner:

<link rel="stylesheet"
      href="{{- (index .Site.Data.manifest "main.css") | relURL -}}" />

<script type="application/javascript"
        src="{{- (index .Site.Data.manifest "main.js") | relURL -}}">
</script>

Handling images

All images have to be loaded through Webpack first using file-loader and optional image optimizations to get them included into Webpack manifest.json and Hugo’s static files. It’s done by placing all original images into assets/images directory with special Javascript entrypoint which will recursively import each image file.

/* assets/images/index.js
 *
 * Webpack helper to import each image asset file.
 */

function requireAll(r) {
  r.keys().forEach(r);
}

requireAll(require.context("./", true, /\.(jpg|png|gif|svg)$/));

Images in templates and partials

After images are included in static site data using importer entry point hack they are referred in templates just like script and style files:

<img src="{{- (index .Site.Data.manifest "logo.png") | relURL -}}" alt="" />

Using Hugo’s internal templates

Hugo contains nice set of internal templates providing markup for usual social media integration and SEO metadata. These includes features which would create Twitter card and Facebook preview images if those are defined as .Params.images array in content front matter.

I haven’t figured any other way than copying those internal templates from Hugo sources to my site’s partials and modifying them to get image filenames from .Site.Data.manifest and converting them to absolute URLs with absURL pipe.

Here’s Twitter cards partial for example:

{{ if .IsPage }} {{ with .Params.images }}
<!-- Twitter summary card with large image must be at least 280x150px -->
<meta name="twitter:card" content="summary_large_image" />
<meta
  name="twitter:image:src"
  content="{{ (index $.Site.Data.manifest (index . 0)) | absURL }}"
/>
{{ else }}
<meta name="twitter:card" content="summary" />
{{ end }}

<!-- Twitter Card data -->
<meta name="twitter:text:title" content="{{ .Title }}" />
<meta name="twitter:title" content="{{ .Title }}" />
<meta
  name="twitter:description"
  content="{{ with .Description }}{{ . }}{{ else }}{{if .IsPage}}{{ .Summary }}{{ else }}{{ with .Site.Params.description }}{{ . }}{{ end }}{{ end }}{{ end }}"
/>
{{ with .Site.Social.twitter }}<meta name="twitter:site" content="@{{ . }}" />{{
end }} {{ range .Site.Authors }} {{ with .twitter }}<meta
  name="twitter:creator"
  content="@{{ . }}"
/>{{ end }} {{ end }}{{ end }}

Images in posts and other site content

Custom shortcode had to be created for using images inside blog posts and other Markdown content. I created following layouts/shortcodes/image.html:

{{- with (index $.Site.Data.manifest (.Get "src")) -}} <img src="{{- . | relURL
-}}" {{- else -}} <img src="{{- .Get "src" | relURL -}}" {{- end -}} {{ with
.Get "alt" -}} alt="{{- . -}}" {{ end }} />

It is used in blog content like:

{{‌< image src="cat.jpg" alt="Cat picture" >‌}}

Other media

Other media like audio or videos would be included just like images.

Install and configure media type specific webpack loader / file-loader
Use manifest.json directly from templates or create custom shortcodes.

Parsing MessagePack in Rails > 5.1

Thu, 29 Jun 2017 12:30:00 +0300

This is an update to earlier post where MessagePack body was parsed to controller params using Rack middleware. That approach relied on ActionDispatch::ParamsParser which got deprecated in 5.1 while custom mime type params parsing got simpler.

For parsing MessagePack request body as controller parameters with Rails > 5 you’ll need msgpack gem and then you are able to provide custom mime types and parsers as ActionDispatch::Request.parameter_parsers array.

Include gem 'msgpack' in your Gemfile
Register mime type for Rails
Configure parameter wrapping similar to json behavior or as you see fit in your case in config/initializers/wrap_parameters.rb
Configure custom parser in eg. config/initializers/parse_msgpack.rb

MessagePack parser configuration

Include following in config/initializers/mime_types.rb to register msgpack mime type.

Mime::Type.register "application/msgpack", :msgpack

Include following in Rails initializer file. For example config/initializers/parse_msgpack.rb.

# Create parameter parser for MessagePack
msgpack_parser = -> (raw_post) { MessagePack.unpack(raw_post) || {} }
ActionDispatch::Request.parameter_parsers.merge! msgpack: msgpack_parser

See this example project for more details about configuration and example on writing MessagePack related controller tests.

Book review: CSS Secrets by Lea Verou

Mon, 04 Jan 2016 18:45:00 +0200

During holidays I finished book CSS Secrets by Lea Verou. I think its the best CSS book I have encountered. It presents 47 everyday design problems with well thought out alternative solutions using latest CSS features.

First chapter gives short introduction on how CSS standards are formed and presents some best practices for writing CSS. That introduction chapter itself changed the way how I have been thinking the DRY principle regarding CSS. Before my interpretation of DRY CSS did limit in clever use of selectors etc to maximize re-usability / minimize file size. However book presents DRY as a design which could be changed with minimal number of property changes.

Rest of the chapters are actual design problems with solutions divided into several categories like typography, user experience, backgrounds, animations etc…

Pros and cons of each alternative solution are discussed and each problem is worked towards solution as DRY as possible without adding extra HTML wrappers when not absolutely needed. Solutions are also designed in a way that won’t sacrifice possibilities to extend designs with animations or other related effects. Also upcoming but yet unimplemented standards are presented if they would offer even better solution someday.

Author doesn’t waste pages on discussing browser support issues because they are in constant flux and CanIUse.com provides more accurate information anyway.

Book is aimed for people with intermediate to advanced CSS knowledge and I personally would recommend it to everyone working with Web front-end or design.

First impression is made once

Tue, 03 Nov 2015 17:23:00 +0200

A short story on my really swift and decisive comparison of transactional email as a service services.

After I noticed that Mandrill has dropped free tier from their pricing options I took of to find alternative to be used while prototyping and with a small scale hobby stuff.

I quickly browsed through Elastic Email, Mailgun, Postmark and Sendgrid. From them I chose Mailgun and Sendgrid to a closer inspection.

Both of them were quite even in feature-wise. Sendgrid offered 12k free monthly emails and Mailgun 10k. Both had HTTP api, SMTP, custom domains, TLS, DKIM, SPF and impressive lists of services using their product containing everybody’s favorite startups.

I continued by registering test accounts – starting with Sendgrid. After registration I had to wait for confirmation mail, opened verification link and got forwarded to a really terrifying marketing info questionnaire containing dozen required input fields.

I got scared and retreated…

Next up Mailgun. Filled in registration form and immediately got forwarded to a confirmation page containing Curl example on using the service sandbox and sample source code snippets for a number of alternate languages. Instant success!

Parsing MessagePack to Rails params

Fri, 23 Oct 2015 20:00:00 +0300

Update ActionDispatch::ParamsParser has been deprecated in Rails 5.0.

Below solution works for Rails versions before 5.1 where ActionDispatch::ParamsParser got removed.

Checkout this post for similar implementation in current Rails versions.

Recently I had to develop Ruby on Rails app which would handle MessagePack formatted request bodies as well as JSON. By default Rails makes parsed JSON available at the params object, and I wanted MessagePack content to be handled just like that.

ActionDispatch::ParamsParser is a Rack middleware responsible for this behavior. Extending it to support other serialization formats could be done in following manner.

I started by including mgspack_rails to Gemfile and then wrote my custom middleware at app/middlewares/custom_params_parser.rb extending ParamsParser to preserve default behavior.

class CustomParamsParser < ActionDispatch::ParamsParser
  def initialize(app, parsers={}, &block)
    super app,
          parsers.merge({
            Mime[:msgpack] => lambda {|raw_post|
              data = ActiveSupport::MessagePack.decode(raw_post)
              data.is_a?(Hash) ? data : { _msgpack: data }
            }
          }),
          &block
  end
end

Then I replaced default ParamsParser in the middleware stack by including following to the config/application.rb:

config.middleware.swap 'ActionDispatch::ParamsParser', 'CustomParamsParser'

It should be noted while writing tests, that middleware stack is not available at the functional controller tests. Integration tests have to be used when it’s necessary to include request body data to params or to test custom middleware like the one above.

Getting react-native running on Fedora 22

Wed, 07 Oct 2015 20:27:00 +0300

I had a little bumps along the way following react-native’s OSX only instructions while setting up development environment on my Fedora 22 system, so here’s quick notes how I got it up and running.

Installed Node v4.1.2 using NVM

Installed OpenJDK from Fedora repos

 sudo dnf install java-1.8.0-openjdk java-1.8.0-openjdk-devel

Installed tools only version of the Android SDK

After those steps I created test project and tried to run react-native and adb port forwarding

adb reverse tcp:8081 tcp:8081 && react-native run-android

… encountering following output:

… lots of log output snipped away …

java.io.IOException: Cannot run program “/opt/android-sdk/build-tools/23.0.1/aapt”: error=2, No such file or directory

… lots of log output snipped away …

Execution failed for task ‘:app:mergeDebugResources’.

> Crunching Cruncher abc_ic_ab_back_mtrl_am_alpha.png failed, see logs

Fierce googling provided me information that issue was caused by 32 bit aapt and it could be fixed by installing 32 bit versions of shared libs it required:

sudo dnf install zlib.i686 libstdc++.i686

Summary

Install node version 4.*.* with NVM
Install missing 32 bit libs
Reverse forward 8081 port for react-native to be able to fetch JS bundle

Secure storage for http basic auth credentials with Git

Sun, 21 Dec 2014 21:14:00 +0200

Lately I have been pushing to a couple git repository over https instead of usual git+ssh and the workflow felt a little bit tedious because by default git asks for http auth credentials before every action.

Fortunately I stumbled upon gitcredentials which allows git to use gnome-keyring among other possible storages.

Using gnome-keyring

In Fedora using git-credential helper for gnome-keyring is pretty straightforward, because the plugin comes prebuilt in Fedora RPM. All you need to do is:

git config --global credential.helper gnome-keyring

You can check what credential helpers your git version knows out-of-the-box with following shell command:

git help -a | grep credential-

OSX users may find helper for Keychain there and Windows users would probably be able to use wincred helper.

Ubuntu packages have gnome-keyring helper only as source in git documentation folder, so it has to be built first:

sudo apt-get install libgnome-keyring-dev
cd /usr/share/doc/git/contrib/credential/gnome-keyring
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring

After first successful login credentials are stored in gnome-keyring and retrieved from there in future.

Using gpg encrypted .netrc in non-Gnome system

If your are not using Gnome/Unity and don’t like to have gnome daemons running in the background, you could use encrypted .netrc file to achieve similar workflow.

Place .netrc in your home directory where each line contain host, user and password definition in following format:
```
 machine {host name} login {user name} password {password}
```
For example:
```
 machine github.com login johndoe password s3cret
```
Generate gpg key if you don’t have one already:
```
 gpg --gen-key
```

Encrypt ~/.netrc using gpg:

 gpg -e -r {YOUR EMAIL USED IN STEP 2} ~/.netrc

Remove original unencrypted .netrc
```
 rm ~/.netrc
```

Enable credential helper for netrc:

 sudo chmod +x /usr/share/doc/git/contrib/credential/netrc/git-credential-netrc
 git config credential.helper /usr/share/doc/git/contrib/credential/netrc/git-credential-netrc

It will seek ~/.netrc.gpg by default and handle decrypting it.

Extra tip: Use gnupg.vim or epa if you prefer Emacs to ease editing .netrc.gpg.

Fish shell is my new favourite

Sat, 14 Jun 2014 21:08:00 +0300

I decided to take Fish shell to the test drive after running into mentions of it in The Setup blog and IRC lately. It was really positive experience and it’s my default login shell now.

Fish is acronym for friendly interactive shell and it really lives up to its name. It didn’t require any configuration to be able to suggest command completions using history, existing filenames or git branch names for example.

Suggestions will happen while you type similar to URL suggestions in web browsers and TAB completion works like you would expect if you are coming from Bash.

However to get rbenv working I had to include following to the Fish configuration at ~/.config/fish/config.fish:

set -x PATH $HOME/.rbenv/bin $PATH
status --is-interactive; and source (rbenv init -|psub)

And for git status / current branch display as right side prompt I added following:

function fish_right_prompt
  __terlar_git_prompt
end

Editing ~/.config/fish/config.fish is not the only way to customize your shell. Executing fish_config will start web server inside your terminal and open quite nice browser based configuration tool in your default browser.

Introducing WebP extension for Middleman

Sun, 16 Mar 2014 13:44:40 +0200

I have been experimenting with Middleman static site generator by runnning my Finnish hobby blog with it. Lately I stumbled upon WebP image format and because Middleman is quite delightfull to extend with own custom plugins, I wrote WebP converter extension to optimize site performance and bandwidth.

Why should I use WebP images?

WebP is new image format developed by Google supporting both lossless and lossy compression methods. Lossless WebP is about 26% smaller than PNG and lossy version packs 25-34% tighter than equivalent JPEG.

Based on Mozilla’s enthusiasm on mozjpeg project, I think that WebP won’t completely replace other web image formats like jpeg and png, but that won’t actually matter. Browsers that support WebP will include image/webp in Accept request header when requesting images. It means that regular jpeg and png files could be used while eg. htaccess configuration ensures that clients who support WebP will receive it.

It’s good idea to have WebP conversion to complement other image optimization techniques and lower bandwidth required to host sites, because browser’s supporting WebP had about 40% share at the time this post was published.

Using Middleman::WebP extension

Middleman::WebP extension converts all image files found during build. If for some reason converted files are larger than original, the webp version will be rejected from the build.

Extension’s source is hosted at Github and the gem is available for installation at Rubygems.org. It depends on cwebp and gif2webp commandline tools, which are probably available in your system’s software repositories. Fedora user’s have it in libwebp-tools rpm, Ubuntu has it in webp package and OS X users are able to install webp package through Homebrew.

Add following to your Middleman site’s Gemfile:

gem "middleman-webp"

Install gem with bundler:

$ bundle

And activate it in your site’s config.rb to enable build time conversion:

activate :webp

Next web server has to be configured to serve WebP alternatives to clients accepting it. I used following htaccess snippet originally published at Vincent Orback’s github repo.

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_ACCEPT} image/webp
    RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
    RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
</IfModule>

<IfModule mod_headers.c>
    Header append Vary Accept env=REDIRECT_accept
</IfModule>

AddType image/webp .webp

Word about my results

In my experiments I got about 4 MiB savings from WebP while jpeg and png optimizations produced 220 KiB smaller files. That’s quite drastic difference compared to the officially reported 25-34% WebP efficiency and it’s explained by lossy WebP compression that I’m using for all image types at that site because I didn’t notice any visual difference.

Workaround for IDNA problems with Disqus commenting

Wed, 05 Feb 2014 20:19:47 +0200

I’m using Disqus commenting service for both my blogs, which has been great. However the Finnish one lies under IDNA domain name (niemelä.fi) and that has been causing some problems. I noticed that some of the comments were missing and that seemed to depend on which web browser was used.

Disqus maps blog post urls to discussions saved in the service and by default it fetches post url using window.location.href value. Firefox returns that in Unicode format eg. niemelä.fi, while Chrome uses ascii punycode xn–niemel-gua.fi. This behaviour will save two different discussion threads from same post. One for Firefox users and other for Chrome users.

Fortunately Disqus allows overriding the post url using disqus_url variable and Punycode.js library provides Javascript encoding/decoding functions for IDNA domain names. Workaround is following:

var disqus_url = "http://" + punycode.toASCII(window.location.host) + window.location.pathname;

punycode.toASCII() function will convert domain name only when it’s in unicode format so it will be safe to call it always.

I merged older comment threads using migration tools at Disqus by uploading url mapping file in CSV format after aplying this workaround.

Translating UI texts in Jolla applications

Mon, 06 Jan 2014 21:46:07 +0200

During this weekend I did a little application for Jolla phone, which displays free parking places in parking halls at Oulu using open data provided by the City of Oulu.

There weren’t too many UI widgets in the app, but it provided great opportinity to look into how localization is made in Sailfish apps. I refined my notes from going through Qt documentation to this post.

1. Generate UI texts using qsTr function

Function qsTr() is used to mark texts for translation, and for providing fallback text if translations are not available.

PullDownMenu {
    MenuItem {
        text: qsTr("Refresh")
        onClicked: model.reload()
    }
}

More sophisticated uses of qsTr like adding context or parameters is shown in QtQuick internalization wiki article.

2. Generate/update ts files from sources

Command line tool lupdate is used to scan source files and find qsTr calls from them. It creates new *.ts file, or updates old one, which will contain translation info, source and target languages etc in human readable XML form.

In Fedora systems lupdate and lrelease tools could be found in Yum repositories from qt5-qttools-devel package and they are installed as lupdate-qt5 and lrelease-qt5.

I used following command to scan *.qml files under directory qml in my project, and to generate ts file for Finnish under i18n directory.

$ lupdate-qt5 qml -ts i18n/translations_fi.ts

3. Translate texts

Normal text editor or Qt Linguist found also in qt5-qttools-devel as linguist-qt5 binary is used to add finished translations to *.ts files.

Below is example i18n/translations_fi.ts from my project.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE TS>
<TS version="2.1" language="fi" sourcelanguage="en">
<context>
    <name>Listing</name>
    <message>
        <source>Refresh</source>
        <translation>Päivitä</translation>
    </message>
    <message>
        <source>Vacant</source>
        <translation>Vapaana</translation>
    </message>
</context>
</TS>

4. Generate *.mq files used with application

Lrelease tools is used to generate binary *.mq files for translations which are actually used by application.

$ lrelease-qt5 i18n/translations_fi.ts -qm i18n/translations_fi.qm

5. Include translations in RPM

Add following lines to *.pro file in project root to make Sailfish SDK include translations in final RPM package.

i18n.path = /usr/share/your-app-name/i18n
i18n.files = i18n/translations_fi.qm

INSTALLS += i18n

6. Enable translations in application for current system locale

Translations for current locale are loaded during initialization phase of the application. Below is an example main -function which loads translations and installs translator for the app.

#include <QtQuick>

#include <sailfishapp.h>

int main(int argc, char *argv[])
{
    QScopedPointer<QGuiApplication> app(SailfishApp::application(argc, argv));

    QTranslator translator;
    translator.load("translations_" + QLocale::system().name(),
                    "/usr/share/harbour-carpark-oulu/i18n");
    app->installTranslator(&translator);

    QScopedPointer<QQuickView> view(SailfishApp::createView());
    view->setSource(SailfishApp::pathTo("qml/harbour-carpark-oulu.qml"));
    view->show();

    return app->exec();
}

QTranslator handles loading of translations and provides localizations for the application while QLocale handles determining current system locale.

QScopedPointer handles memory management for app and view instances and frees them automatically when main() finishes.

Don’t worry if QLocale::system().name() returns “C” when application is run in debug mode. There’s probably a bug in SDK and it works properly when application is launched from the application menu on device.

Mosh: SSH alternative for unstable networks

Sat, 28 Dec 2013 15:05:24 +0200

SSH is great tool for connecting your machines remotely, but the user experience suffers from high latency of cellular networks and IP address changes caused by unstable network or changing between cellular/Wifi will drop the connection and will require manual reconnecting.

Mosh is a SSH alternative which solves these issues in pursuit of developing ideal remote shell application for mobile use. It’s available for multiple Linux/Unix distributions in their repositories, OS X with Homebrew, Android and you can compile it for Jolla phone too.

Usage examples

Installation in Fedora:

$ sudo yum install mosh

Mosh will initiate connection through SSH and it will use that connection to start actual Mosh server at the remote host, so mosh-server have to be available at the remote host. Usage is similar to command line SSH:

$ mosh username@remote-host

Using custom port for initial SSH connection:

$ mosh --ssh="ssh -p 2222" user@remote-host

Usigin specific private key for authentication:

$ mosh --ssh="ssh -i ~/.ssh/other_key" user@remote-host

How it handles roaming and network delays

Mosh command used in above examples is a wrapper script which starts mosh-server at the remote host using SSH and then connects local mosh-client to that server.

Mosh client and server communicates using UDP protocol. UDP doesn’t have persistent connection like the TCP used in SSH and that allows changes in local host’s IP during the session.

Both Mosh client and server stores the state of the displayed screen and uses local echoing to prevent network latency from interfering text input by the user. In comparison, SSH requires full round trip before it will display the given input.

How I setup development environments with Vagrant

Mon, 23 Dec 2013 16:07:25 +0200

Having test environment as similar as possible to your production setup is a must to prevent problems caused by different software versions or configuration. I also like the freedom to try out different web development frameworks, database servers, etc without cluttering up my actual desktop system.

It’s possible to achieve all these by running development environment in virtual machine and Vagrant is an application which makes setting up virtual machines and sharing them with coworkers easy. Additionally it will be simple to re-create your setup when re-installing or changing your OS or hardware with the help of Vagrant.

First time setup for a project is described here and if you are participating in a project where Vagrantfile is already present first two sections here contains steps for getting started with it.

Installing Vagrant and dependencies

Install VirtualBox from official site or your system repositories. In Fedora this could be achieved by:
```
 # yum install VirtualBox
```
Download and install Vagrant from the official site. There are packages available for all popular systems.

Setting up Vagrant for your project

Following command line is used to initialize Vagrantfile for your project.

$ vagrant init {box-name} {box-url}

For example when using default Ubuntu Precise Pangolin box provided by Vagrant project, it is initialized with following:

$ vagrant init precise32 http://files.vagrantup.com/precise32.box

I have created my own minimal Debian Wheezy based box, which is available at: https://iiska.kapsi.fi/vagrant/wheezy32.box

Next start virtual machine:

$ vagrant up

This will download base box from given url if it’s not already available locally and configure it according to the Vagrantfile. Directory containing the Vagrantfile will be mounted to /vagrant in the virtual machine using NFS.

Accessing virtual machine using SSH is possible with command:

$ vagrant ssh

Creating custom base images

It’s quite simple to bake your own base box for vagrant virtual machines. Basically it’s possible to package any VirtualBox machine as a Vagrant base box with command:

$ vagrant package --base {machine-name-in-vbox}

However there should be user vagrant with sudo rights present and all non-necessary services and applications should be pruned to minimize base box size.

Mike Griffin has written a great article about creating minimal Debian Wheezy base box which I recommend to get more detailed information.

Of course there are images provided by Vagrant itself so it’s not always necessary to bake you own.

Provisioning

To be able share set of installed apps and configuration without including them to the base box it is necessary to provide script for installing them with you Vagrantfile.

Vagrant supports number of configuration management systems like Chef and Puppet but I have been using simple shell scripts for now.

Here’s simple example about installing basic LAMP setup in my wheezy base box.

#! /bin/bash
# Simple install script to run as shell provisioner for vagrant
export DEBIAN_FRONTEND=noninteractive
# Refresh apt repositories and install updates
apt-get update -q
apt-get upgrade -yq
# Stuff for LAMP environment
apt-get install -yq mysql-server apache2 php5
# Initialize test database
echo "CREATE DATABASE IF NOT EXISTS testing_db;" | mysql -u root
echo "GRANT ALL ON testing_db.* TO 'test_user'@'localhost' IDENTIFIED BY 'password';" | mysql -u root

If file above is saved as Vagrant-setup.sh following should be included in the Vagrantfile.

config.vm.provision "shell", path: "Vagrant-setup.sh"

Now that script will be run when vagrant up is called first time or vagrant provision is run.

Test Driven Development with Enyo framework

Sat, 30 Nov 2013 11:56:58 +0200

Enyo is Javascript frontend framework which we use at ZEF a lot. It emphasizes re-usable modular widgets named kinds for building the UI and its main targets are mobile platforms, however it is usable on conventional desktop web applications too.

There’s little information or examples about practices considering test driven development while using Enyo and I’m a little bit uncomfortable with the aproach which could be seen at the core Enyo repository, so I decided to create own setup using tools I like more and are quite popular with other open source projects.

Why test driven development?

I like TDD because it consistently builds up confidence in your codebase and makes refactoring and helps catching regressions after the test coverage is good enough.

Creating test code before actual implementation has also a nice side effect which shapes your application/library to contain more natural feeling interfaces, because you actually try to use them from your tests before they even exist.

Of course it demands extra work and discipline to create tests and keep them up to date, but I feel that the rewards of the TDD are well worth the effort.

Basic setup

There are great number of different Javascript based unit test frameworks. I chose QUnit because of it has clean and simple API and nice way of testing asynchronous callbacks.

GruntJS is similar to the Rake in the Ruby ecosystem or Make in the traditional C programmer’s toolchain and it handles running test tasks when test or implementation files change or it is invoked from the command line.

Jordan Kasper’s blog has a good post covering setting up grunt and QUnit for testing jQuery plugins and I used that approach as starting point to include Enyo specific changes.

For this setup you need to have Node.js and NPM installed. Those are required only during development time and it doesn’t really matter if your actual app won’t have anything to do with Node. Those could be installed from Node.js site or from your systems package repositories. I mainly use Fedora which has them pre-packaged and available through Yum:

$ sudo yum install nodejs npm

Example Enyo based project displaying this test setup is available at my Github repositories. That example is adapted and modified from the Enyo bootplate template.

Setting up Grunt

Following package.json will have the minimal content required for installing Grunt tasks and Qunit that is all what you need if you are not developing Node app.

{
  "name": "Your-project-name",
  "version": "1.0.0",
  "devDependencies": {
	"grunt": "~0.4.1",
	"grunt-contrib-qunit": ">=0.2.1",
	"grunt-contrib-watch": ">=0.3.1",
	"qunitjs": "~1.12.0"
  }
}

You have to install grunt-cli package globally to be able to use grunt with your project, but all other dependencies are installed automatically by npm with the help of package.json above.

Install grunt-cli globally:

$ sudo npm install -g grunt-cli

Install other packages, by running following in the directory containing package.json:

$ npm install

Packages are installed under node_modules directory and it’s good idea to include that in your .gitignore file to prevent cluttering your repository or git status output.

Grunt tasks are defined in Gruntfile.js shown below. Grunt-contrib-qunit and grunt-contrib-watch packages will handle all the heavy lifting related to those tasks and Gruntfile.js includes only configuration for them and loading of those tasks.

module.exports = function(grunt) {
  grunt.initConfig({
    pkg: grunt.file.readJSON("package.json"),
    // Set qunit test files
    qunit: {
      all: ["tests/*.html"]
    },
    // Set files which are watched and define task which is
    // run after changes
    watch: {
      files: ["tests/*.js", "tests/*.html", "source/**/*.js"],
      tasks: ["qunit"]
    }
  });
  // load up your plugins
  grunt.loadNpmTasks("grunt-contrib-qunit");
  grunt.loadNpmTasks("grunt-contrib-watch");
  // register qunit test run as default task
  grunt.registerTask("default", ["qunit"]);
};

Now command grunt qunit will run the tests and grunt watch will start watcher process which runs tests automatically when changes are detected.

Basic test setup with Enyo libraries

QUnit tests are run by a browser which in this case is headless PhantomJS browser run by Grunt task, but it is possible to open test files in regular browser too.

Tests are defined by using at least one html file and as many js files containing test modules as you need. Tests for Enyo apps will need html done in following fashion.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />

    <title>Enyo Qunit Example tests</title>

    <link rel="stylesheet" href="../node_modules/qunitjs/qunit/qunit.css" />

    <!-- 1. include Enyo and other external libraries which are required by your app -->
    <script src="../enyo/enyo.js" type="text/javascript"></script>

    <!-- 2. include actual JS files of your application -->
    <script src="../source/package.js" type="text/javascript"></script>

    <!-- 3. include QUnit test framework -->
    <script src="../node_modules/qunitjs/qunit/qunit.js"></script>

    <!-- 4. actual tests -->
    <script src="example_tests.js"></script>
  </head>
  <body>
    <div id="qunit"></div>
    <!-- QUnit will use this for test results -->
    <div id="qunit-fixture">
      <!-- Render content which is relevant for your tests here -->
      <!-- Content of #qunit-fixture is reseted before each test -->
    </div>
  </body>
</html>

Above HTML file loads your app’s dependencies, your actual app, QUnit test framework and runs included tests. Element #qunit is required for the QUnit tests results and #qunit-fixture will be used for rendering your app components which are under testing. Note that #qunit-fixture will be cleared before each test.

Actual test code is shown in the following snippet. There is a couple simple test cases where the first only asserts that component under test is really available and the second one makes sure that it could be rendered properly. Element #qunit-fixture is used as a rendering target.

module("Simple example tests");

test("HeaderBar kind is defined", function() {
  ok(HeaderBar);
});

test("HeaderBar is able to be rendered", function() {
  var node = document.getElementById("qunit-fixture");
  var bar = new HeaderBar().renderInto(node);

  ok(bar);
  ok(bar.hasNode());
});

Capturing Enyo events in tests

Testing that planned events trigger properly and do what they should is important step in testing and capturing events during tests is required. We need to add a little extra test code to handle events in the Enyo way.

Here’s the actual component which we are testing:

enyo.kind({
  name: "HeaderBar",
  kind: "onyx.Toolbar",

  events: {
    onButtonPressed: ""
  },

  components: [
    { name: "title", content: "Example Flickr photo listing" },
    {
      name: "button",
      kind: "onyx.Button",
      content: "Press this!",
      ontap: "handleButton"
    }
  ],

  handleButton: function(inSender, inEvent) {
    this.doButtonPressed({ button: 1 });
  }
});

For capturing custom events I use another kind specified only for test purposes, which will register event handlers. Those handlers will do the assertions to check that all was triggered properly.

Test code will also handle the triggering of the event like shown in the following snippet.

module("Example event handling tests");

test("HeaderBar triggers onButtonPressed when user taps it's button", function() {
  // Helper kind for catching events
  enyo.kind({
    name: "TestKind",
    kind: enyo.Control,

    components: [
      { name: "bar", kind: "HeaderBar", onButtonPressed: "handleEvent" }
    ],

    handleEvent: function(inSender, inEvent) {
      // Event is fired and bar component has provided data with it
      // that contains element named button with value 1
      equal(inEvent.button, 1);
    }
  });

  var node = document.getElementById("qunit-fixture");
  var obj = new TestKind().renderInto(node);

  // Trigger ontap from button
  obj.$.bar.$.button.bubble("ontap");
});

Mocking Ajax

Web application usually depend on other web services but testing single component should be independent from other services, because you wouldn’t know if the failure is caused by the bug in you component or error in the other service. Simulating failure handling is also easier if you aren’t testing against the actual service.

Using mock objects and method stubs is common way to decouple tested component from external dependencies. For stubbing requests triggered from Enyo’s WebService, Jsonp and Ajax kinds overriding go method in the related request kind is simple way to achieve this with Enyo 2.2.0. However this won’t work in upcoming 2.3.0 so I have to find new or modified aproach for that.

For time being following test setup is enough for Enyo 2.2.0 apps.

module("Example Ajax tests");

test("Photos will call Flickr api when initialized", function() {
  enyo.JsonpRequest.prototype.go = function test() {
    ok(this.url.match(/^https?:\/\/api.flickr.com/));
  };

  var node = document.getElementById("qunit-fixture");
  var p = new Photos().renderInto(node).render();
});

asyncTest(
  "Proper error message should be shown when request fails",
  function() {
    enyo.JsonpRequest.prototype.go = function test() {
      this.fail();
    };

    var node = document.getElementById("qunit-fixture");
    var p = new Photos().renderInto(node).render();

    setTimeout(function() {
      ok(p.$.error.getContent().match(/Unable to load/));
      start();
    }, 10);
  }
);

And this is the componen under test:

enyo.kind({
  name: "Photos",
  kind: enyo.Control,

  create: function() {
    this.inherited(arguments);

    new enyo.JsonpRequest({
      url: "http://api.flickr.com/services/feeds/photos_public.gne",
      callbackName: "jsoncallback"
    })
      .response(enyo.bind(this, "renderPhotos"))
      .error(enyo.bind(this, "renderError"))
      .go({
        id: "72148715@N00",
        per_page: 10,
        lang: "en-us",
        format: "json"
      });
  },

  renderPhotos: function(inSender, inResponse) {
    this.destroyClientControls();

    enyo.forEach(
      inResponse.items,
      function(item) {
        this.createComponent({
          tag: "img",
          attributes: {
            src: item.media.m,
            title: item.title
          }
        });
      },
      this
    );

    this.render();
  },

  renderError: function() {
    this.destroyClientControls();
    this.createComponent({
      name: "error",
      content: "Unable to load photo listing..."
    });
    this.render();
  }
});

I really like using Webmock gem while coding in Ruby when I need to do similar mocks so finding or developing something like that would be ideal for me. And of course I have to find some kind of solution for handling mocking requests similar fashion in Enyo 2.3.0.

If you have some ideas on testing Ajax requests in 2.3.0 or other tips how to improve my overall testing aproach please leave a comment.

About this site

Sun, 24 Nov 2013 18:23:21 +0200

I have been planning writing blog posts in English for quite a long time and I have dreamed on finding or building some kind of holy grail of multi-language blogging engine.

Now I finally decided to abandon that quest and launched separate site named “Byte Plumbing” for English content.

I’m probably going to focus in software and web development and stuff related to my daily work in that field here while I keep posting on my Finnish blog about other hobbies and freetime activities. It’s also possible that I’ll translate some posts from there to here or vice versa.

Under the hood of this blog

This blog is generated with Octopress, which is blog framework designed for Jekyll static site generator.

Because this is static site I need to use 3rd party service for comments. I have chosen Disqus for that.

I collect statistics using self hosted Piwik installation, which will honor the Do Not Track header.