A Great Weekend

The weekend started on Thursday (13th March 2014) by a series of talks by some young entrepreneurs at the Linus Torvalds auditorium (Exactum building, Kumpula campus of University of Helsinki). We learnt some key facts and points about lean startups and also characteristics and goals of prototypes.

The Joy Began

Next day (Friday), SomeJam hackathon officially began at the Happi Youth Center, with some initial speeches about the fundamentals and practicalities. Then we teamed up, and the organizers started to ignite the creativity rocket of participants by showing some objects and asking us to guess what it is, and how it can be used. Then we started to think about and come up with some ideas to solve the loneliness problem of youth. After some minutes of brainstorming in groups, all groups presented their ideas.

Finally, we had a freestyle opportunity to come up with some novel ideas and present them. First, I came up with a great novel idea (related to youth) and presented it, but since we only had 48 hours to build the prototype, I thought more time is needed to build a working prototype of my idea. Then I noticed another great idea proposed by Maninder Singh, and I joined the team. Then Lei Wang and another anonymous teammate joined our team.

The idea was to provide a service to lonely people and those who are new in a city, especially youth, to find and join events based on their interests, make new friends, and have fun. After joining the team, we started to discuss about the details, and we came to an agreement for the programming language and technologies we wanted to use. We chose the Grail framework because we all knew Java, and Grails was a great framework for Java programmers, because it is relatively easy to learn, developers can develop their solution quickly using scaffolding facilities, and it’s almost hassle-free. I already knew Spring framework and Maven, and it helped me to learn the new framework rapidly.

Welcome to The Dragon Team!

Friday night, we started to brainstorm more and then collaborate to draw our initial model on a big piece of paper. We managed to come up with a model that satisfied our initial requirements. It’s worth to mention that this model might not be complete in the first iteration and can be improved over iteration (like in lean and agile processes), but we tried to consider and model the fundamental building blocks accurately.

We created a paper prototype demonstrating the features and functionality of our intended service. We also created a central repository on Github to facilitate our teamwork for implementing the service initially as a web-based service. Since the IntellijIDEA IDE offers out of the box support (code completion, server management, etc.) for Grails, we used that IDE for our project. After working till 4 AM on the backend and a part of frondend, we left Happi to have some rest at home.

On Saturday, we get together again at midday because we had to pitch and defend our idea and project in a tough jury meeting.

Fortunately, we managed to defend our idea, and of course we got some precious suggestion and advises that we considered for improving our service. After the meeting, we continued to work till late night.

Time to Wrap Up

On Sunday, we got prepared to present our software product (working prototype), and I believe we did it pretty good. You can watch the footage on YouTube.

Eventually, the amazing weekend came to an end, but the inspiration did not. I learnt a lot in the first SomeJam.

The Guru!

I believe the following advices may come in handy:

1. Don’t miss this kind of events! When I got the email regarding this course, I thought I’m not going to participate because I was busy, but it turned out to be one of the best courses I have ever had.

2. It’s great to have some novel ideas to solve our problems, but since these kind of hackathons are quite short, bear this in mind that you must be able to implement a prototype in a short time. So don’t consider ideas that need a week or two to build even a prototype.

3. Although prototypes are there to quickly show the concept, but they should impress/persuade the investors/partners/business angles for investing in your idea. So take this into account before going to the pitching meeting.

4. If you didn’t face a good reaction/feedback from the potential investors, don’t be frustrated, the objective of a prototype is to assess if the idea is worth to put more effort in order to implement it. Instead, think about other novel ideas.

5. You can predict the reaction/feedback of your potential investor to some extent. Try to ask yourself:

– How are we going to have our first user/customer?

– How can we extend our user base, and how are we going to keep them motivated such that they continue to use our service?

– What value(s) does our service offer to users?

-Can we imagine of a Persona for our users?

– Is there any similar service out there? If yes, how does our service differ from those similar ones?

– Does the project need significant investment to set up? What about the maintenance costs?

– Can we generate a revenue stream?

I learnt all of these in this intensive event. Thus, in the end, I would like to express my gratitude to dear Hanna Mäenpää, dear Emilia Hjelm, dear Marcus Lundqvist, other organizers, and my teammates for creating this great experience.

HappyHangup is a platform which provide solution to the lonely people in a country. For a new person in a country or lonely people in country, its hard to find friends. We provide group activities to involve people with others. Its going to be unique platform where youth organization can generate innovative solutions and execute those innovative ideas by involving youth of the country. It provide a unique interface where youth can interact with each other and find new friends. It a platform to have a fun whiling hanging and being a part of learning environment.

This idea is come up by our group member Singh Maninder.  The following paper is his initial idea. After Maninder‘s presentation,  Javad Boh, Jannis Seemann and I joined the group.

The following chart is the Singh Maninder‘s original idea.

Then, we start to figure out how to go specific on this idea together. The following figure is our discussion result about what specific feature we need to realize.

 

The final presentation of our project on Sunday is http://www.youtube.com/watch?v=Jp4MzFrpw88

Github repository: https://github.com/jsmunich/HappyHangup

Open source license: MIT

We use the grails for web development framework and gsp for front end design.

The following pictures is our website ‘s snapshots.

Main page of our work.

 

Interests list of users

 

coming activities list

 

involved Company list

 

Details of Activity

 

 

We have a really happy experience together to complete the whole project, and we also want to get comment from users.

By Mukesh Thakur  from LetsDoIT Team

As a developer i would say it is really important for a programmer to take part in this kind of event not only to challenge their programming skills but also to challenge their social skill and to get out of their comfort zone to make some innovative project in very short period of time. The most important thing in this kinda of event is communication and co-operation between team member to solve the problems and get things done. And of course chatting with other people is also important since u will get to meet new interesting people which is so much fun.

Choosing tools for software development could be tool, one is comfortable with or one is eager to learn. As for our team , we decided to use Ruby on Rails , since it is much more faster for protyping and Appgyver for initial protoyping( desgining ). Apart form this we sketched on the paper for modelling and we sometime argued to get to the conclusion which is very good. We used Git as base code repo since everyone of us knew git and it is super easy to use and maintain, share code.

Something on should remember in this kind of event is , it is team work , so all the work should not be done by one team member but work should be divided among all team member , nobody should be left out. Dont be afraid to speak on stage , it is not that difficult . One practical issue i would say is remember to sleep at some point or productivity decreases and yes remember your brush if u are not going home.

 

 

For SomeJam, I joined a project that wanted to unify various online youth services. There are many different support groups and person-to-person chats provided by different charities. It can be confusing for a young person to track all these different services each with their own opening hours. Our team consisted of two youth service workers, myself, and another software developer, who was not a student at Helsinki University.

After brainstorming for a few hours, we came to the conclusion that persuading all the different organizations to adopt new software would probably not work. Thus, we felt it wiser to provide our own portal service, that displays the currently open support discussions at a glance. A worker on behalf of the portal service would monitor the schedules of the various services and maintain the information on the site.

Once the project had been defined, it was quite straightforward to implement the site. Our second software developer had other work to attend to, so for the first half of saturdayI didn’t need to worry about development environments and other details of group software development. I quickly hacked together a JQuery/JavaScript frontend that used a static JSON file as a data source. The data source listed the events, grouped in personal and group events, and contained the links and opening hours of the event. This was organized by the front-end and displayed to the user.

Later in the afternoon saturday, the other software developer joined, and started work on integration with a calendar service. He had previous experience with Google App Engine, and so chose that as the platform. Using the Google Calendar API, he created a parser that parsed the events on the current day to the same kind of format I had used on my front-end. The parts fit together neatly, and we had a working prototype by sunday.

 

 

Thoughts for future SomeJams

Thoroughly discussing the problem paid off, since the original problem setting was not something that we could have feasibly answered in the given 48h constraint.

By focusing our efforts into a small and obvious problem, our product has a good chance of becoming a real service. The feeling that we can actually build something for the betterment of society was an invaluable source of motivation for the team.

 

It was quite interesting to attend SomeJam and to innovate things as a practical developer. The working environment was quite enjoyable and comfortable, with a lot of space.  Staffs were quite considerate and the food was nice.

Our schedule for the SomeJam -event was generally like this, on Friday evening we first had an introduction to the event and self-introduction of everyone. Then we were randomly divided into groups and had games to inspire us to solve problems. On Saturday afternoon we had our first pitch with board members and got feedback to improve our future work. Then on Sunday afternoon, we did the final pitch among all the other teams.

In terms of team work,  we all thought that our team worked really well together. All of us were developers so we were instantly on the same page in terms of what was doable in the scope of 48 hours . We also had similar ideas about how we should start implementing the project. After the initial planning phase we decided to divide into two groups, so that we could have a nice mock-up done for Saturday’s board meeting but also immediately start work on the Rails prototype.

It was quite useful and interesting to pitch, as majority of our group members didn’t have real pitching experience yet. We gained valuable experience on how to form a good idea and try to sell it to business investors. Working as group and solving a problem together in real life was very interesting. We all learned a lot not and hoped to enjoy the next SomeJam event.

Software development team members

Martin Radev

Describe your software concept shortyly:

To develop a tool that recognises hate speech based on a cumulative database of hate speech cases. The database will contain cases of different kinds of hate speech (e.g. hatred based on ethnic background, sexual orientation or gender identity, religion or disability). The more the programme knows, the better it recognises new cases.

What became your solution architecture?

Java for the socket server. PHP for connection between http server and socket server. JavaScript for the connection between the website and the http server. MySQL for storing the training examples. For recognizing the topic of the text it was used a text-mining library and most accurately the LSA algorithm.

Are you satisfied with the architectural choices your group made for the software?

No, because there were issues getting jsp working locally. We had to go with the java app to listen on a socket and receive the data via the latter. Then, we had to send the post requests from the website to a php script and then send the data to the main program via a socket connection. The initial idea was to make it as a standard webapp and deploy it to heroku.

Description:

Just moved to a new city and don’t know anybody? Or are you feeling lonely in company cause none of your friends really get your passion for My Little Ponies? No matter what your interest are, there are people with the same passion out there. FIHMY will help you to find these new friends! The web service is super easy to use, also with mobile devices. With just a few clics you are able to mark your interests and see how many registered users are interested about the same things in your area. Then you can jump in the events organized by other users around an interest. Or you can set a date and invite eg. other local My Little Pony fans to meet you. When you meet face-to-face, you will all know that you have something to babble, rally or gossip about. And that, dear folks, could be a start of a beautiful friendship.

Link to the presentation: http://www.youtube.com/watch?v=RIq08aVHtlc

Technical:

Back-end: NodeJs + ExpressJs + MongoDB

Font-end: AngularJs

The back-end solution worked well, NodeJs allowing for quick and dirty solutions to be made which sped up the production.

The front-end was a learning process… The only experienced AngularJs developer in the team had to leave and the two others had to wrangle with it the rest of the project. But it worked quite well in the end. AngularJs is like magic, with its automatic dependecy injections and two-way data binding. What made the AngularJs development process easier was the desicion to use a Yeoman generator for the project. It allowed us to ignore many aspects of how AngularJs works, and concentrate on the essentials.

 Advice

• Keep it Simple, Stupid (KISS). Kill features, kill some more features and then cut the features in half.
• Do not think about code quality. Just hack it together and get things done. It doesn’t matter if the server crashes when the client gives the wrong data, as long as it works during the demo.

 

 

On SomeJam, we were supposed to develop a rapid prototype a platform where users are able to participate in events, and browse them. In this blogpost, I will focus on what we experienced when we wrote our prototype using the web application framework grails.

Why grails? Since everybody in the group already knew java – and groovy is a language which is easy to learn for java developers, we were all okay with the programming language itself. Furthermore, I already had some experience developing an application with this framework, and I knew it really increases productivity.

Once we had defined our relational data model, we used grails scaffolding capabilities to generate an admin menu, and were then able to push a first version of this code to github, so that everybody was able at the same time to develop a different part of the application. The MVC pattern allowed us to separate the project into a few modules, and each of our group was then working on a different module.

The disadvantage of this framework is that the dependency handling might cause some troubles, especially if 2 incompatible versions of the same software are to be loaded by the same time, then you have to fix this issue by yourself. Also, it requires quite a bit of memory, so you should have at least 4 gigabyte, better 8gb or more memory.

All in all, I can highly suggest to give grails a try, especially when rapid protyping an application or developing an application for a commercial context – scaffolding, great testing capabilities and a great integration of existing java code allow a fast and reliable development cycle.

 

Text written by a participant that wishes to remain anonymous 🙂