Mynewsdesk Devcorner

Last day, I had to serve some html pages via HTTPS. But didn't really know any simple solution to do this.

Here is one. A simple wrapper of the python SimpleHTTPServer with support for SSL.

Before running the server, you'll need to create your certificate :

<code>openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes</code>

Now that you have your certificate, create a file srv.py :

gist

Add this file to your path, or simply call it from wherever you want like that :

/path/to/srv.py

This will serve the file in your current directory on https://localhost:4443

If you need a non httpS version to simply serve som static file, you can use the standard python simpleHTTPServer like this :

python -m SimpleHTTPServer

The new Network feature on Mynewsdesk will introduce a lot of new ways you can manage a contact. For instance, adding social media profiles and links to each contact.

To keep the user input as easy as possible, we wanted people to basically just paste urls and then it would be parsed into social media profile objects it possible (we use some of them to fetch content from their API). Pasting links works well for social media profiles that aren't username heavy, like Facebook, but not for Twitter or Instagram, which is very username heavy, so the logical way to add a new profile for them would be to add a provider and username only.

We built this logic about a month prior to today, but needed it for two apps in our infrastructure, so we've been converting it and extending it to a gem, which we've published to rubygems today.

Here's how it works.

parser = SocialMediaParser.parse "https://www.facebook.com/teamcoco"
=> #<SocialMediaParser::SocialMedia::Facebook:0x007fe014ef0f78 @url="https://www.facebook.com/teamcoco"&gt;

parser.username
=> "teamcoco"

parser.provider
=> "facebook"

parser.url
=> "https://www.facebook.com/teamcoco"

If you instead want to construct a profile using provider and username options, you can use this

parser = SocialMediaParser.parse provider: "twitter", username: "fallontonight"
=> #<SocialMediaParser::SocialMedia::Twitter:0x007fe40ab08330 @provider="twitter", @username="fallontonight">

parser.url
=> "https://www.twitter.com/fallontonight"

When there's not enough input provided for SocialMediaParser to extract a valid profile, it will just return a Link object

parser = SocialMediaParser.parse url: "http://www.mynewsdesk.com"
=> #<SocialMediaParser::Link:0x007fe40ab9b770 @url="http://www.mynewsdesk.com"&gt;

parser.url
=> "http://www.mynewsdesk.com"

parser.username
=> nil

That's it, really. We hope to find this useful to someone!

This post is here to help you get started.

For this post, we are going to create a Todo Application, using vanilla JS so that we can test everything.
The final app demo is here : http://b2l.github.io/todo-app/html/todo.html
And the application code is here : https://github.com/b2l/todo-app

Before we get started, let's create the project directory and jump into it :

mkdir todo-app
cd todo-app

The tools

This project is really basic, so we won’t set up any assets compilation.
We will just have an html entry point that will load any file we need.

We will use the following libraries to test the application :

• Mocha (test framework)
• ChaiJs (assertion library)
• selenium webdriver (from the selenium website: "Selenium automates browsers. That's it!")

Let's install them :

npm install -D mocha chai selenium-webdriver

Mocha provide a Command Line Interface that makes it easier to launch tests, so install it:

npm install -g mocha

Selenium work by having a java application that control the browser. You, as a client, connect to this web server and send it some command.

To use selenium, we need the selenium java server. Download it from here : selenium standalone server

We will need the path to the jar file you just downloaded.

Project structure

The project is a full frontend project, so we will need some JavaScript, CSS and HTML.

Let’s create a structure for this.

mkdir html
mkdir css
mkdir js
mkdir tests

Unit testing

Let's create our first test.

Our todo application will manage a list of todos. So we want to be able to :

• create a todo
• get a todo
• get all todos
• update a todo
• remove a todo
• mark a todo as done
• mark a todo as not done

Here is a part of our test file :

tests/todo-model.js gist

Before looking at the implementation, let's run the test :

mocha tests

Ok mocha complains that the file ../js/Todos.js doesn't exist. Let's create it now :

js/Todos.js gist

Run tests again :

mocha tests

And we are done !

Interface test

The test workflow with selenium is as follow :

• Run the selenium server
• Create a client with options
• Execute command

Everything is a command, or an action, from asking selenium for a node matching a selector to clicking somewhere or closing the browser.

The first point can be achieved in different ways, either by a script which manages the server, or we can start / stop it from the test.

We will use the second option, here is the file to initialize the server :

selenium-server.js gist

I won't go through the todo-application implementation because it's not the point of this article.

If you want to follow this step by step, just copy the css, html and js directories. Run our application :

python -m SimpleHTTPServer

You can test your application here : http://localhost:8000/html/todo.html

Here is the interface test :

tests/todo-interface.js gist

To run the interface test, we can use the same command as before :

Before we run the test: if you are a user of tmux (screen should have the same issue), please note that you will have to attach the selenium server to the user space as describe here : http://borkweb.com/story/chromedriver-doesnt-run-in-tmux

mocha tests/todo-interface.js

You can see a chrome browser starting in background and interacting with our application. Awesome !

Conclusion

There you are ! We have extracted and tested the domain part of the application (the Todos model) and we have test that the interface work properly too. You now have a small setup for testing your frontend application.

Sometimes when working with Rails objects with relationships in memory, strange things can happen. You can edit the attribute of some object and when accessing it using a relationship, the changes will be gone. It has to do with in-memory objects and how ActiveRecord handles them. But there is a way to make sure you always work with the same object.

inverse_of is a Rails relationship option that will optimize object loading and can be really helpful when you're working with object in memory a lot. It's not very well documented, so I thought I'd write a small blog post about it.

The setup:

If I were to open up a console and add a Post with two Comments, I could then do this:

Console gist

The last few lines does seem weird, doesn't it? I was banging my head quite a bit after discovering this. But here's inverse_of to the rescue! Please note the pluralization of comments, it maps to how the inversed relationship will be used.

Gist

Using inverse_of will trigger ActiveRecord to optimize object handling. In other words, it will use the same in-memory object when it's the same object and accessing it the way the inverse_of relationship has been configued.

Inverse of gist

It has a few limitations and you can read some more about it in the Ruby on Rails documentation.

A few weeks ago Github released Boxen, a “tool for automating and managing Macs at GitHub”. At Mynewsdesk, with more than ten developers and a handful of projects, we can see the need for this kind of software. When summed up, many days have been spent trying to get developer laptops back in a working state for one reason or the other. We also had a lot of smart configurations, custom hacks, different versions of databases, sometimes shared with some collegues but without a central repository of collaboration for this kind of configurations.

At Mynewsdesk we’re using Chef for setting up and configuring our server environment. Boxen didn’t feel like a perfect fit for us, since it’s based on Puppet. Puppet and Chef are the two main competitors in this area of operating system configuration management.

To solve this we’re now presenting Chefup. The pipe dream of Chefup (and Boxen) is to be able to install a full developer machine with a single command. But more than that it also provides a way of keeping the machine in a working state, with all key components fully documented. As a bonus this can all be done without running sudo and wreak havoc with your system. Some cookbooks may themselves run sudo though, such as homebrew and pow.

Initial Setup

1. To begin with, clone our open source project from Github;
   

   git clone git://github.com/mynewsdesk/chefup.git

   
   If you still don’t have git installed you may want to curl it instead;
   

   curl -L https://github.com/mynewsdesk/chefup/tarball|tar xz

   
   That will get you a version without the .git directory but you can make a proper clone later on, when you have access to git.


2. To be able to compile you also need to install XCode from App Store.You’ll need to agree to the license by running;
   

   xcodebuild -license	

   
   


3. Now create a Cheffile. That’s a list of external Chef cookbooks to be installed.
   

   cp Cheffile.example Cheffile

   
   If you work at Mynewsdesk and have access to our private repos you may uncomment the chef-mynewsdesk repo to setup our apps.


4. After this you want to decide exactly what Chefup will install for you. This is done in the node.jsonfile. An example is provided for you so you want to begin with copying it.
   

   cp node.json.example node.json

   
   Now have a look at that file. In the header you enter your personal data in form of name and email. Then you choose where you want to keep your code, where the default is ~/dev.

   After that have a look at the run list. That’s a list of packages, or cookbooks in Chef terminology.



5. Now, logged in as your normal user, run;
   

   bin/chefup	

   
   This will install the bundler and librarian-chef gems, the homebrew and dmg cookbooks and any cookbooks listed in the run list in node.json. If you have chefup-bin in your run list you will have chefup in your $PATH after the first run, so it will be enough to just run chefup.

   Any backups of overwritten files are kept in tmp/backup. Any installed apps (with an .app suffix) will be installed in ~/Applications to avoid needing root permissions.

Living with Chefup

If you miss something, feel free to add a cookbook. Either as a new git repo and adding it to Cheffile. It will then be installed to cookbooks in the next run. Or by cloning the chefup-repo, adding cookbooks to site-cookbooks. Then please feel free to send a pull request to have it added to the official repo, if it could be of use to others.