"If you want to know what games are in the App Store, check Joao’s phone."
— Antti Salonen
August 19, 2011
June 30, 2011
"We need more elements!"
— Kisko Labs quote of the day
June 7, 2011
Introducing Carpentry
Today we’re releasing one of the few gems that we use internally, making
it available to everyone.
Carpentry is a tool that
enables designers to focus on what they do best, without worrying about
implementation details.
Workflow
Designers can now manage their own prototypes, without needing to worry where they are going to end up when implemented. Once ready, a developer will pick the file, move it to the appropriate place and wire it to the Rails application. Designers don’t need to care about controller design, and can try more in less time.
By default, prototypes are accessible when the application is deployed.
Now clients can see them and provide feedback before anything is
implemented. If you don’t want prototypes available to everyone, don’t
worry. There is an overridable before filter where anything can be
added, such as authentication or a redirect if in production.
Getting started
To start using Carpentry, all you need to do is add it to the Gemfile
and run rails generate carpentry:install.
The gem adds an directory (app/views/carpentry/prototypes) to a Rails
project where prototype files go into, and makes them accessible at
/p, following the same structure as the prototypes folder. So, if you
have app/views/carpentry/prototypes/clients/new.html.haml you can
access it at /p/clients/new.
Behind the scenes
Carpentry is not only useful, but it’s also available to prove a point.
Creating a Rails engine is easy, and a great way to extract
functionality that is needed in several Rails applications. In fact, the
whole gem has only 50 lines of code, including a Rack middleware, and a
Rails generator.
Let’s take a look at the code.
First of all, there is the controller that catches all prototype
requests and renders the correct file, in
app/controllers/carpentry/prototypes_controller.rb:
We call the #before_carpentry before filter only if it is defined.
Since we inherit from ApplicationController, the method can be added
there. The second argument in #respond_to? defines whether to look at
private methods or not. In this case, we want that.
We also need to add a route to send the requests to our
PrototypesController, in config/routes.rb:
Notice that we define that /p should render an index file if it
exists, by setting the file_path parameter to index.
We configure our engine in lib/carpentry.rb so that Rails knows that
our gem is an engine, and to use a middleware that we’re bundling with
Carpentry:
Our NoRobotsMiddleware is very simple. It does nothing more than
adding <meta name="robots" content="noindex, nofollow"/> before the
end of the <head> tag so that prototypes don’t get crawled and indexed
by search engines. The middleware is defined in
lib/carpentry/no_robots_middleware.rb:
Hope this helps you understand how to build an engine. Look at the source code on GitHub and the specs we have if you’re building a small engine and don’t know where to look for examples.
If you’d like to learn more, you should probably get José Valim’s book Crafting Rails Applications.
May 29, 2011
Google OpenID authentication using Devise and Omniauth
Since I spent one hour getting this thing to work and there is no single post clearly explaining what to do, I’ll post my findings here. Big thanks to Julián Porta for his post on the topic. That set me on the right track.
First of all if you want to do authentication with Google, you need to use OpenID. Oauth is only for allowing you an access to data.
Steps (I’m assuming you have a working Devise installation):
//Antti
May 26, 2011
Introducing sproutcore-rails
At Kisko Labs we’re good at picking great tools. We’ve been using Rails ever since we started in 2007 and haven’t looked back. We hope to keep on using it for many years to come.
However, we need more than just Rails. We need a powerful tool for frontend development that fits our projects. That is why we are extremely happy with the announcement of SproutCore 2.0. There is no way we could have used SproutCore 1.x on all our applications, but as of version 2 that is no longer true.
Within a few hours of the announcement and release of the first alpha version, we created the sproutcore-rails gem. At the moment it only contains the latest SproutCore 2.0 developer preview for use with Rails 3.1 and its awesome asset pipeline. We will keep an eye on SproutCore development and update the gem as needed. We also hope to include Rails helpers to help with Rails/SproutCore applications if needed. We’re very much open to contributions from both communities.
Today is a good day to be a web developer.
// joao
May 24, 2011
Introducing Snowfinch: open source realtime web analytics
Snowfinch is an open source realtime web analytics application built with Ruby on Rails and MongoDB. The project was developed as a part of my thesis, and has then been released under the MIT license.
The application focuses on what is happening right now on your site. To a user it works just like most other analytics products: sites can be tracked by adding nothing more than a JavaScript snippet.
The dashboard view for a tracked site is very simple. It shows three counters (active visitors, pageviews today, and unique visitors today) and a chart containing both the number of pageviews for the current day as well as the previous day. Both the chart and the counters are updated every second.
There is also a text input where a URI can be pasted, and a similar dashboard is displayed for a single page of the site. This seems like a much better solution than a large list of every single page that has been tracked.
In addition to the dashboard, Snowfinch provides a very neat monitoring tool. Monitoring is done via sensors. At the moment two types of sensors exist, but more can be developed.
The first sensor type is the query based sensor. This sensor is triggered when a page URI contains a given query key and value. It can be used, for example, to monitor campaigns.
The other sensor is the referrer based sensor. This allows tracking of how many entries to the site there are from any given number of referrer hosts. An example use case is adding twitter.com and facebook.com as referrer hosts to see how much traffic you are getting from social media sites.
For each sensor, a chart displaying the number of entries is shown.
It doesn’t have all the features in the world at this stage, but if you’re interested in hosting your own web analytics application, this is a project you’ll want to keep an eye on.
I already have a small roadmap shown below. If you have any further suggestions, I’d love to hear them.
- Display data for any given period of time (currently the past 2 days).
- Collect and display referrer information.
- Custom visitor tagging.
- Geographic location of visitors.
- Filter by custom page metadata (e.g. for A/B testing).
- Asynchronous data collector.
If you’re looking to contribute, go ahead and start coding. I’m taking a small break from developing it, while I readjust myself to working full time, but development will continue.
The code is available on GitHub and you can reach me at joao@kiskolabs.com.
// joao
May 20, 2011
Why Frozen Rails will never charge our speakers a penny
If you follow Chris Wanstrath (@defunkt) on Twitter you might have noticed these two tweets yesterday:
DjangoCon Europe charges speakers $$$ to talk. Absolutely disgusting.less than a minute ago via web 
Favorite 
Retweet 
Reply
Chris Wanstrath
defunkt
We wanted to sponsor but the DjangoCon Europe organizer blew me off when asking about the speaker $$$ thing. Stay classy.less than a minute ago via web Favorite Retweet ReplyChris Wanstrath
defunkt
…and then controversy.
To clarify, DjangoCon doesn’t charge their speakers to speak, per se, but does charge them the regular admissions fee (400–600€, by the looks of it).
I’d just like to give a few of the reasons why we would never charge our speakers a single penny at Frozen Rails.
1. They make the conference possible
If we didn’t get the great speakers we do there would be no conference. Every time we get a speaker who accepts an invitation to come speak at Frozen Rails, we’re incredibly grateful for it.
2. Some speakers implicitly sponsor us
We’re perfectly OK with paying for some of our speakers’ travel costs and accommodation, but the economics of organising a small conference don’t let us pay for every speaker and certainly make it impossible to pay a respectable speaker’s fee to any of them.
Every time a speaker (or their company) agrees to pay for their own airfares and hotel, it’s incredibly beneficial for us and helps us keep the price of the tickets down. (By the way, if you want to make a pot of money, don’t go into the conference business)
3. Many of our speakers go above and beyond the call of duty
All of the speakers we had at last year’s Frozen Rails were incredible nice people.
For example, Chris and Ryan (@rtomayko) from GitHub actually volunteered to help us with assembling the attendee packs (which involved assembling about ~300 folders) after the speakers’ dinner on the night before the conference.
And then after the conference they had a GitHub meetup with an open tab at the bar for most of the night. Oh, and all of this was after GitHub paid for both Chris and Ryan’s flights and hotels.
4. We care about putting together the best possible conference we can
Not only do we want to have great speakers at Frozen Rails, we also want to make sure we have a great audience. To help with this we do things like offer discounts and free tickets to Rails contributors. That’s right, if you have enough commits to Rails you get a free ticket to Frozen Rails. Even a single commit will get you a 10% discount.
Another reason why we offer these discounts is that we like to encourage people to get involved, which is also why we offer steeply discounted student tickets (at below cost, even).
// Matt
May 18, 2011
Responsive jQuery Slideshow
This example makes it possible to have fluid jQuery slideshow which scales responsively. This is the same method which is used on the new kiskolabs.com.
I am using Jonathan Snook’s Simple jQuery Slideshow in this example, but you could really use any JavaScript solution with this HTML/CSS combo. I think it’s easiest if I just show the source code and provide live example for you to try out.
HTML:
CSS:
JS:
That’s all. Did you expect it to be more complex? : )
// Viljami, @viljamis on Twitter
UPDATE:
I made an updated version of this, read the new blog post at http://viljamis.com/blog/2011/responsiveslides-js.php and check out the plugin here: http://responsive-slides.viljamis.com/.
May 18, 2011
Making kiskolabs.com responsive
Responsive Web Design is a methodology for designing web sites that can adapt to a range of screen sizes and device types. I’ve personally been a fan of responsive design for a long time, following people like Jeremy Keith, Ethan Marcotte and Luke Wroblewski. I also think, that in many cases, there shouldn’t be a separate mobile site or separate mobile content. Because of all this it seemed obvious that our new site would also be responsive and work with wide range of devices/screen sizes.
Usually, when designing responsive layout, it’s easier to design a content heavy site without much functionality. But with a site like the new kiskolabs.com which has more functionality, it can be more challenging.
Of course I could have just dumbed down the content of the desktop version to make the process easier, but that would be against my own paradigms. Also assuming that the mobile users are in a completely different context than the desktop users, or assuming that they have only one context, is just arrogant. It can also be annoying for the user if a feature he wants isn’t included in the mobile version.
Sometimes there might be a clear need for more separate mobile site, but this wasn’t the case now anyway. One thing to keep on mind though is that this approach only solves the viewport problem.
“The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.”
- Tim Berners-Lee
“Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.
More and more people are using mobile devices as a primary means of accessing the web. The number is already huge and it’s increasing every day. I don’t think they’re all using their devices just to look up the opening times of restaurants. They are looking for the same breadth and richness of experience that they’ve come to expect from the web on other devices.
Hence the frustration with mobile-optimised sites that remove content that’s available on the desktop-optimised version.”
– Jeremy Keith
The Process
I usually tend to start on paper doing sketching & wireframes and after that jump to Photoshop or to a Web Browser to test and mockup my ideas. This time the process were a bit different. I had a quite clear vision on my mind and I started executing it straight in the browser, doing most of the design work there with CSS3. Occasionally I jumped to Photoshop, for example, to do the background of the site.
After finishing the 940px wide design and most of the JavaScripts I started implementing CSS @media queries to add the responsiveness. I ended up using six breakpoints to trigger the media queries. Those were respectively 970, 840, 740, 600, 480 and 320.
While writing the CSS I have usually several different browsers open and also iPhone & iPad on the desk showing my localhost. On my Mac I have iOS simulator, Opera Mobile simulator and Android simulator in addition to the native browsers. I do most of the previewing in Desktop Safari and use the Webkit’s inspector and at times make sure that it looks like it should in Opera Mini for example. Depending on the case I might also make sure that everything works with Nokia’s and other manufacturers phones.
One interesting design aspect of the site is, that the sticky main navigation jumps to the bottom of the page when viewing on smaller widths and a “Skip to site navigation” link is displayed on top. Same kind of approach is used on Mobilism 2011 site. Ended up using that approach mainly because the navigation would’ve otherwise filled up the whole screen of small device and I prefer more “content first” approach.
Difficulties with fluid design
One tricky part was the work section. There’s a JavaScript slideshow for every work and they open inline inside the same section. The slides in the slideshow have one image per slide and the browser loads those images only after user has clicked a link. That’s really where the tricky part begins - Everything should be fluid. At first I thought I’d just write here how this problem is solved, but I ended up doing a second blog post about that. you can find it here: Responsive jQuery slideshow
Other techniques used
First thing worth mentioning is a JavaScript plugin called FitText. It makes font-sizes flexible, which means that you can achieve scalable headlines that fill the width of a parent element. Another great JavaScript plugin is jQuery Waypoints, which makes it easy to execute a function whenever you scroll to an element. It’s used for the navigation, highlighting and scrolling.
The site is also made so that you can add it to your iPhone’s home screen and use it like a native application. This is done by adding few meta tags to the page head and thus removing Safari components, customizing the default status bar style and adding an icon for the site.
Further reading and references:
- Kisko Labs: Responsive jQuery slideshow
- Jeremy Keith: One Web
- Jeremy Keith: Context
- Ethan Marcotte: On being responsive
- A List Apart: Responsive Web Design
- Jason Things: More Responsive Design, Please
- Tim Kadlec: Responsive Web Design and Mobile Context
- Joaquin Lippincott: Stop! You are doing mobile wrong!
- Stephen Hay: There is no Mobile Web
- FitText: A plugin for inflating web type
- jQuery Waypoints
// Viljami, @viljamis on Twitter
May 13, 2011
Extend your Sass
When I started to work with Sass a while ago I was a little disappointed on how much excess CSS was generated. Although these optimizations don’t matter so much when the client CSS gets minified I still wanted to find a way to have more control on what Sass generates.
(The examples below are using the .scss syntax, Sass also has another syntax called .sass)
The most obvious new layer of abstraction that Sass adds to CSS is the @mixin. The documentation writes:
Mixins allow you to define styles that can be re-used throughout the stylesheet without needing to resort to non-semantic classes
Styles defined in the @mixin can be used in CSS selectors with the @include directive. @mixins are very powerful tools, but sometimes you don’t need all that power.
@include vs @extend
@mixin:s should be used as a function, to calculate something, to generate something with a variable or to implement complicated scaffolding hierarchies. The problem with using @mixins is that they duplicate the styles whenever you use @include.
Sass has also another useful tool, the @extend directive. @extend adds the properties of a existing class to where you’re extending, but in a way that it’s not bloating the CSS. Creating @extendable CSS classes can be thought as prototype-model. Below is an example of the output using both @extend and @include.
Pros:
Obvious style sources
Wynn Netherland wrote about the problems with of using @mixins.
When using multiple classes, the Firebug style inspector can take me to the exact line where the style was defined.
With the mixin approach, these styles are now mixed into each rule. Firebug will of course show me the styles in each rule, but now I don’t > know where they come from unless I leave my browser and traverse my Sass code.
Using the @extend directive has the advantage of creating obvious style sources that can be debugged immediately in Firebug.
Less CSS
As the example above states, choosing the appropriate tool will generate less CSS.
Feels more right
Using @mixins when you need function-type behaviour and @extend when you have a more prototype approach will make your code more sensible.
Cons
Namespacing the @extendable classes
Biggest problem with the @extend directive is a namespacing one. You want them to not interfere with your HTML classes. I’ve used “kisko-” prefix to ensure this.
Maybe harder to maintain
Using both @extends and @mixins might make the Sass code harder to maintain in the long run instead of just going only with @mixins.
// Antti Salonen @salantsa on Twitter
RSS feed: http://blog.kiskolabs.com/rss
1 of 4
Next page
