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.
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.
Somejam. A coding event during the the weekend, 48 hours to develop an idea together. No mandatory sleep. And we liked it. Our software development team was only 3 people: me (Agostino Sturaro), Karri Rasinmäki and Victor Rodrigues
Our idea was to help young people find a reason to break their routines, visit new places, possibly get out more often. Indeed, this was a social initiative as well as a startup exercise in prototyping.
For this, we used a concept that is familiar to people that spend lots of time in front of their tech gadgets playing online. The “fog of war” that hides the unexplored portions of a map that appears in many games involving exploration. This translates to a knowledge of visited zones, where the fog has cleared, and gives an idea of how much of the game zone is still unknown.
We thought, if people could see how much of their own city they never visited, maybe we can also give them a reason to go look around. Positive feedback is having your explorations recorded shown to you.
We named our concept FoggyMap, and started developing right away. The goal was to have something that can be used on any smartphone, so users could use that to track their positions when going around.
If you are a developer, or just interested in the details, here’s our report.
First, we made a paper prototype. Little tech involved, but it was necessary to visualize the idea. It helped to clear our mind and, in hindsight, the final result was pretty close to that we sketched together. Then we went around asking people to try it. When we had to explain people how to use it, we decided to make it even simpler.
We were working with different tasks at the same time and finally put it all together. That allowed faster developing when every one of us had clearly dedicated task.
It started as a way to try more than one solution, and have a backup plan in case one of those failed. One member was developing the concept as a web app, while the others tried doing so as an Android app. The web app was ready before the Android app, but we still needed a way to save data in a reliable fashion and gathering position data in the background. We came to the conclusion that we could wrap the webapp inside the Android app to gain that functionality.
What became your solution architecture?
For the limited time we had, we are satisfied with the underlying hybrid structure of the application
pros: fast development; possibility to use much of the code (all the webapp) on many platforms; we got it working in 48 hours
cons: wrapped JS solution is a bit slower than native, Android app still not that reliable
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.
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.
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?
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.
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.
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.
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 🙂