by Mirek Woźniak 31 January 2012

Have you ever wondered how loud, exactly, is that noisy crossroads that prevents you from having a well-deserved sleep? Is it really comparable to a herd of starting jumbo-jets pursued by a swarm of fighter planes? How could anyone put up with this madness?

Worry not - we’ve got a solution to your problem and it’s called AirCasting.

AirCasting is an Android application that measures noise pollution. It’s a light, flexible and free-for-all Android app we created for HabitatMap.org with funding from Google’s Charitable Giving Fund of Tides Foundation.

AirCasters measure sound levels, which they can choose to contribute to a crowd sourced map of noise pollution. This allows everyone to see the best place to either walk your dog, wind down and meet your mates or, simply, test your brand new protective earplugs.

All right, all right, you may say. Buzzwords don’t impress me anymore. I would like some facts. How does it work in practice?

Sound level measurement started in New York City. Its inhabitants complained about noise to a City hotline. The usual hustle & bustle affected their sleep, health and overall well-being. As a tool to justify their claims, AirCasting becomes a vessel for public opinion. Local authorities may dismiss one claim unsupported by any evidence, but what about hundreds of noise pollution reports made on the spot?

AirCasting has been developed by three Lunar Logic pros: Paweł, Marcin and Grzesiek (he was testing the app). I’ve asked Paweł some specific questions about AirCasting.

Mirek: What does AirCasting do, in a nutshell?
Paweł: AirCasting is a platform for sharing and visualising environmental data. Currently the only supported kind of data are noise levels. These can be obtained by users with their phones and then shared through our website.
M: Which parts of the smartphone does it use?
P: Most prominently we are using the microphone to gather noise level data. Other than that we are using Google Maps to visualise the data the user and others have gathered.
M: Are there any planned extensions for the app?
P: The app is planned to support a wide range of environmental sensors with which it will connect via Bluetooth. The one that's being engineered right now is a gas sensor for measuring pollutant concentrations in the air.

AirCasting has been live since 20th December 2011 and is available free from the Android market. The source code is available under GPL:

https://github.com/LunarLogicPolska/AirCastingAndroidClient https://github.com/LunarLogicPolska/AirCasting

by Paul Klipp 25 January 2012

Most web startups struggle and many fail. For almost a decade, I've been watching it happen up close. As the owner of a custom web development agency I've had front-row seats to rare moments of glory and spectacular failures. When I encountered the customer-centric approach promoted by Steve Blank in The Four Steps to the Epiphany and more recently popularized by Eric Ries in The Lean Startup, I was excited, because it described so nicely a solution to many of the problems I've witnessed over years of watching startups launch. I've seen founders blinded by the brilliance of their own vision fail to adapt to the demands of their users and miss crucial opportunities to adapt, or pivot, in Lean Startup jargon.

The idea of the customer-centric approach is to build a product largely driven by feedback from users. This way you have a successful product that you can be sure solves real user problems.

In 2009, we built one of the first online Kanban board applications because we needed one to work with remote clients and nothing like that existed at the time. We later decided to offer the product to the public and for the first time I was the product manager of a web startup and I could apply principles I had learnt over a decade in software development. Initially, my decisions about Kanbanery were primarily driven by principles such as team empowerment, flexibility, transparency, trust, and ease of use. For the details, however, I looked to user feedback.

Getting that user feedback would prove a major challenge. What tools could be used to obtain the necessary feedback from users in order to overcome the challenges of our first product? It was in answering this challenge that the second product we created emerged: the Engage! engine for user engagement.

Like other startups, we had two alternative solutions to the problem of obtaining user feedback. The first solution was to use a hosted service such as GetSatisfaction or UserVoice while the second solution would mean developing our own support tools from scratch.

I didn't want to distract us from our main task of working on Kanbanery, so I opted for the hosted solution but frustration was quick to set in. The frustration was largely due to the same problems most companies face with the use of one-size-fits-all hosted applications, in that they offer a limited range of customization. Also, using this tool meant that users had to leave our application and create a new account on another application in order to provide feedback and this confused a fair number of users. I was also faced with an awkward financial decision. Any of the 30 people in my company might help to support users by answering questions or engaging with them in the feedback forum, but at $25 or more per person per month, I had to decide who would get accounts and who wouldn't.

We're about to change all of that with our own software solution to user feedback and engagement aptly named 'Engage!'.

'Engage!' is customer engagement tool that plugs seamlessly into any Ruby on Rails application running Rails 3.1 or higher. It can work right out of the box with a simple installation and configuration script, but it's designed to be easily extensible and skinnable. It has all the basic features you'd expect from a ticket tracking and customer support forum but no more.

If you have half an hour to spend installing it, it will just work, but if you want to add one more feature or change the style to match your site, you easily can. It will also tie into your own authentication service for a seamless user experience, or you can use it's own built-in authentication system if your application doesn't require users to have accounts.

'Engage!' is a Rails Engine, which means it's a stand-alone application that can be added to any Rails 3.1 or higher application as easily as installing a gem. The best part is, the code will be free to non-profit organizations and open source projects, and a lifetime license will be available to web startups for a low, one-time fee. You can have as many users as you like and customize it to your heart's content without ever paying again.

If you're interested, sign up at engage.llp.pl and we'll contact you as soon as the first version is ready to release. We'll let you know when you can download it for free and start hacking at it as you like. We'll only ask you to pay for it if you install it in a commercial product. We'll be inviting beta testers to use it free of charge, so please let us know if you're interested.

If you have any questions about 'Engage!' or suggestions, we'd love to hear them. Just use the comments below.

by Jakub Suder 19 January 2012

Everyone at Lunar Logic is good at something. And since no one is good at everything, it's nice to be able to share the knowledge and skills.

One of the ways we do that is an internal event we call "workshops". Technically, these aren't workshops in the strict sense, but rather technical presentations with a lot of examples, where someone explains to everyone interested how to use some kind of framework or technology.

I've recently done one such workshop, titled "Introduction to iOS development". This time, we've decided to make an experiment and record it as a screencast, and share it with everyone. We think it worked out pretty well – sorry for the sound quality though, let's hope it will be better next time.

The screencast is mostly intended for people who haven't done much iOS development (or none at all), to give them a general idea what it looks like. It first shows how to generate an application from a template, what this application does and what each part of code is for. Then I quickly go through the code of an example application – a simple client for RubyTime, our time tracking webapp. I also show some examples how to use LunarToolkit, an ObjC library we've shared recently on GitHub (note: it's referred to by its old name "PsiToolkit" in the screencast). If you've already written an app or two in UIKit, you might want to skip straight to around 22:00 where the RubyTime part starts.

If you're just starting with iPhone development and ObjC code seems to you like something written by aliens, I also recommend that you read this blog post I've written some time ago, which explains the basics of the language to developers familiar with some other popular languages.

If you want to play with the code yourself, here are the GitHub projects:

• RubyTimeExample - https://github.com/LunarLogicPolska/RubyTimeExample
• LunarToolkit - http://github.org/LunarLogicPolska/LunarToolkit
• RubyTime - http://github.org/LunarLogicPolska/rubytime

by Mirek Woźniak 4 January 2012

We decided at LLP that such event as Global CodeRetreat Day needs something more to commemorate it than just report and photos.

We prepared a short report to let those who weren't at the event taste the atmosphere and for the participants - to remind them of the whole day spent on creative coding.

Thank you once more for coming! You can read the report from Global CR Day and see the photos.

by Adam Pohorecki 3 January 2012

Software Craftsmanship in Kraków (shortly SCKRK) is a reading club that gathers every other Wednesday over a beer sponsored by Lunar Logic Polska to discuss articles and books related to Object Oriented Programming, Testing, Software Architecture and other interesting topics.

The club was founded by our own Adam Pohorecki, and over last year SCKRK, with help from Lunar Logic Polska, has organized two Coderetreats, one of which was facilitated by Corey Haines.

Last week, the club discussed an article written by Kent Beck in 1989, titled "A Laboratory for Teaching Object-Oriented Thinking". This article proposes a new method for describing and designing Object-Oriented applications - CRC Cards.

CRC card (short for Class, Responsibilities, Collaborators) is a small piece of paper, on which the developer notes a name of the designed class, the responsibilities that class has, and the collaborators, which the class in question interacts with. By limiting the space available for the description, CRC cards indirectly enforce limits on the number of responsibilities and collaborators of a class, and by making the developer specify all of the other objects the class interacts with, they help programmers used to the procedural programming style, to get rid of the bad habit of accessing global state.

We started the discussion by wondering whether the method proposed by Beck is still relevant today in the age of agile software development, TDD and pair-programming. Part of the group argued that these days, we do not design the systems upfront, and that the system design should be guided primarily by tests instead of a whiteboard. Others suggested that even if we do not design upfront, we still often stop to figure out what to implement next and how to do it, and CRC cards could be used as a part of that step of the process. There were also people who thought that this method could be used to model the system domain and help establish the Ubiquitous Language (which we learned about when SCKRK was discussing Domain-Driven Design).

Finally, Michał stepped in and suggested that "Teaching" in the article's title is there not without a reason. We all agreed that CRC cards can be a very useful when it comes to teaching programmers Object-Oriented Design and rules like Single Responsibility Principle.

Later we tried to apply CRC cards to design a solution to a problem proposed by Jarek. In this situation in a system there are Places and Users which have Addresses and the view layer of this application presents those Addresses in multiple ways, often quite similar to each other. After some heated discussion, which involved much more hand-waving than card-drawing, we arrived at a satisfactory solution: the Users and Places in this situation do not matter, only Addresses and their Formatting. We decided that the system would consist of an Address class and many AddressFormatter classes, one per possible display format.

Then the discussion started flowing towards Clean Code, and when can one accept increasing technical debt in order to get things done faster. This provoked another discussion about the Lean Startup movement, and what Obie Fernandez says about putting business value before implementation correctness and maintainability of "not business proven" features.

The meeting lasted almost 3 hours and was one of our longest and most attended meetings to date. The next meeting will take place on Wednesday the 4th of January, so if you are in Kraków and you are interested in Software Craftsmanship (or beer), be sure to come!