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 🙂

This is a blog that reports adventurous coding expeditions from the University of Helsinki’s Department of Computer Science.