Overview

Until now, I'm a back-end engineer, but I've participated in hackathons about 7 or 8 times. Among them, I would like to introduce the things that have been useful by using various technologies and products. What I think is important for actually developing in a hackathon

-** The product actually works ** -** The fastest product can be made ** -** Multi-person development **

In that respect, I would like to introduce mainly the products that can realize these. Finally, I would like to introduce some small but important tips for participating in the hackathon. Please be aware that this is aimed at participating in the hackathon and making the product as fast as possible, and there are some security issues.

What is a hackathon?

A hackathon (English: hackathon, also known as hack day, hackfest, codefest) is an event for software-related projects in which programmers, graphic designers, user interface designers, and project managers in the field of software development work intensively. There are cases where we work individually, work in groups, and work on one goal as a whole.

Reference: Hackathon

Most hackathons are events where teams are formed and smartphone apps and web services are created in a short period of about 8 to 24 hours. The ones I've seen are Hack Day, teamLab Hack-Day, SPAJAM, Fish Casson, etc.

Chat (slack)

https://slack.com/

It's a chat tool that I didn't mention. I think that you usually have the image of using it in the company or in a team with people who are remote. Are there any benefits to a face-to-face hackathon? Speaking of which

Check and share progress when preparing for the hackathon
Easy delivery of materials

For example, in what cases is it useful? In other words, it is useful for sharing the information required to log in to the development server, and for sharing the link when you are technically addicted to it and when you search by hand. Also, if you are developing an application, you can replace images and pass enough materials for the site if they are light. It is also useful when passing actual data when making a presentation. On the other hand, "Do I have to use slack?" Is not so. There are other chat work and Facebook Messenger, so you don't have to be particular about it. ** The important thing is to minimize communication costs and material delivery costs. ** **

Shared server (Docker)

Needless to say, it's Docker. It is often convenient to have a shared server, so it is often created. Recently, there is a Dockerfile that the members used in the shared environment, so paste it.

`Dockerfile`


FROM ubuntu:16.04

RUN apt-get update && apt-get -y upgrade && apt-get install -y build-essential libssl-dev libreadline-dev zlib1g-dev language-pack-ja
RUN apt-get -y install openssh-server ufw curl
RUN mkdir /var/run/sshd

#Settings for one user--from here--
#User registration(kotauchisunsun,password)
RUN useradd -m kotauchisunsun && echo "kotauchisunsun:password" | chpasswd && gpasswd -a kotauchisunsun sudo
RUN mkdir -p /home/kotauchisunsun/.ssh; chown kotauchisunsun /home/kotauchisunsun/.ssh; chmod 700 /home/kotauchisunsun/.ssh

#User SSH key registration
ADD ./authorized_keys /home/kotauchisunsun/.ssh/authorized_keys
RUN chown kotauchisunsun /home/kotauchisunsun/.ssh/authorized_keys; chmod 600 /home/kotauchisunsun/.ssh/authorized_keys
#Settings for one user--So far--

CMD /usr/sbin/sshd -D && tail -f /dev/null

Reference: Minimum required to create docker container that can ssh

If you create this Dockerfile and authorized_keys and private_key for ssh, it will work. In the above Dockerfile, a user named kotauchisunsun is added, the password is registered as password, and sudo authority is given. If you copy and paste the part of "# 1 user setting" for the members who participate in the hackathon, change the name and increase it, everyone will be able to ssh. If you divide it into "use only for hackathons", it is safe to paste the private key on slack etc. and share it (although it is completely out if you do it with the actual product) and check that login and sudo work. .. When finished, if you drop the entire server, the server of the mother ship will not be affected. Even if the private key is leaked, it is difficult to be attacked in a short period of time by the hackathon, and even if it becomes a stepping stone for an attack, it is easy to stop the service. The reason why the Dockerfile itself is not created so much is that the types of products and libraries created for each hackathon are quite different, so we prepare only basic containers and leave the rest to the team members.

$ docker build -t sshd_image . 
$ docker run --privileged -d -p 2222:22 sshd_image

This will start Docker and run ssh on port 2222. There is a point that makes me feel like ** Port forwarding is only 22 ports for ssh. ** This will contradict the previous story. It says "it's better to build with microservices", but there is no way for the server on Docker to receive a request from a global IP. Therefore, there are many uncertainties when operating without knowing how many servers will stand like a hackathon. So is there a way to add port forwarding later in docker? (Reference). However, this method is a method of tampering with the server of the mother ship on which docker is running, and if possible, it is a method that I do not want to do. In the next section, we will introduce how to solve this ** "I want to operate with docker, but I want to increase the number of ports to be published after starting the container" **.

Also, do I need to bother to service sshd with this content with Docker? It is said that there is. Time is the most precious thing in a hackathon. Therefore, ** "Oh, I got an ssh error. Permission Denied. Oh, I understand. I made a mistake in the authority of authorized_keys. I often do it. Chmod 600." I don't have time to do it **. If you spend time on such a boring place, it is more convenient to use a stable product.

Port forwarding (ngrok)

https://ngrok.com/

In a nutshell, ** is a service that opens ports globally. ** ** For example, if you want to publish port 80 of localhost in Docker, just download the binary of the above official website and type the following command, and the port will be published with https.

$ ./ngrok http 80
ngrok by @inconshreveable                                                                                                                                                                                       (Ctrl+C to quit)

Session Status                online
Version                       2.2.8
Region                        United States (us)
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://2c8b91ae.ngrok.io -> localhost:80
Forwarding                    https://2c8b91ae.ngrok.io -> localhost:80

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

Only this! Now when you access https://2c8b91ae.ngrok.io, you can make the access fly to port 80 of localhost in Docker. Now you can route as many ports in Docker as you like globally! No user registration required! ** ** ngrok itself has various restrictions in the free plan, but it does not matter so much for use in hackathons. However, one thing to note is that the domain of the free plan changes randomly each time it is started. Therefore, it is necessary to implement a function that can change the domain of the client, or to keep launching the process so that the domain of ngrok once started on the server side does not change.

Static server (python)

If you want to create a web application, a static server is required to put images and js. Even if the thing you want to make is not a web application, it may be convenient to have a server where you can easily see the current UI condition with a smartphone browser in case the designer wants to check the UI on a smartphone. In general, nginx is stable and fast when servicing static files, but personally it is troublesome to introduce. So I,

$ python3 -m http.server

I will stand up with. This will publish the executed directory as it is on port 8000. Therefore, if you put html, css, js in the same directory, you can see it immediately. If you do port forwarding with ngrok earlier, there is no problem with what you see.

File transfer (Cyberduck)

https://cyberduck.io/index.ja.html?l=ja

A GUI client for scp that runs on both Mac and Windows. Actually, this is also the reason why I used to run ssh in a shared environment earlier, and I think it is convenient for designers to be able to transfer files by operating the GUI with Cyberduck. This has a merit on the development side as well, and if an engineer deploys the data to put it into production, it will take time and the designer will have to "wait". This will reduce the efficiency of product development. Therefore, it may be beneficial for both designers if they can deploy by themselves.

Hackathon BE Architect

** We recommend microservices for one server per person **

To do. There are three reasons

** 1. Costly to combine code ** ** 2. You can make the most of your personal strength and environment ** ** 3. When development becomes difficult, it is easy to degrease the function **

As a personal experience, the combined part of the code often takes the longest. At hackathons, I attach great importance to "writing working code", and in many cases, the division of classes and the structure of the program are halfway, and the code is not as beautiful as writing at work. Therefore, multiple people touch the same source code, or the interface of the function is changed without permission due to lack of functions, and conflicts occur frequently. During a hackathon, if someone touches the code and there are conflicts and corrections, it will slow down development. Also, if the code gets stuck due to pulling from github and it takes time to recover it, the product will not work at all for a long time, and it may be mentally cornered. Therefore, "** Avoid code merging if possible " " Even if you do code merging, pay attention to the class interface design and the granularity of functional division, and avoid touching the same source code * * "Is my personal strategy. With the "avoid code merging if possible" approach I mentioned earlier, how do you combine functionally in a multiplayer development? It becomes. My personal solution is ** better to combine as a microservice **. I think it's easiest to build with the so-called REST API. Creating a REST API at the real product level is quite difficult. Recovery from variable validation and proper error handling. There are many points to think about, such as ingenuity for creating a stateful API. However, in the case of a hackathon, it is a major premise that it moves, so that side can be completely ignored. Personally, ** I think the easiest thing is to divide the entry points of POST and URL, and make the body json. The idea is **. In most programming languages, you can request http and you can also make json. On the server side, http can be received normally, and json parsing is also a language standard, so you don't have to think much about it. Due to the characteristics of hackathons, there are many "technical challenges". For example, new gadgets, machine learning libraries, and other challenges are interesting, but they often get stuck around the environment. It's really hard to get stuck around this environment, and the product may not work at all. If a large number of people use a shared development environment and each person starts installing the library as they like, what was working may not work. ** Therefore, it is easy to make something that works as a product by assembling one server and one function per person. ** This has various merits, and since the server is set up by each individual, it is easy to create in a development environment that is easy for individuals and run the product, so the development speed is easy. Also, if you make a microservice and loosely couple modules, when some function does not work and you can not help it, ** module is separated at the server level and degreased to make a product. You can avoid "the product doesn't work" **. But these are really server-side only. Code sharing is essential for iOS and Android development. Actually, this is also a personal issue, and if you make a smartphone app with a large number of people in a hackathon, you will often see hell (especially around the GUI). ** Therefore, in the case of smartphone apps, there is a section where one of the developers who connect the final functions needs a lot of power.

Small but important hackathon tips

Be sure to install the development environment, libraries and run the tutorial in advance.

If you are building a development environment or introducing a library during a hackathon, no matter how much time you have, it will not be enough. Let's do it first. Also, once you build the sample code and make sure it works, you can concentrate on the creation.

Gadget hardware allows multiple people to move the same thing

Recent startup hardware is interesting, and products that use such hardware "look like a hackathon." However, if such hardware is adopted as a hackathon product, the product will be moribund if it does not work well. Therefore, let's make it possible for a few people to move, not just one person.

Be sure to prepare 3 or 4 spare parts for electronic work

I myself have never done electronic work in a hackathon, but the parts are broken. It is (apparently) good to prepare more than one.

Give up on machine learning "learning"

The hackathon lasts a day at the longest and about 5 hours at the shortest. Under such circumstances, learning machine learning and parameter tuning are hopeless. Use existing ones as much as possible.

Bring a power strip and portable Wifi

Hackathons are becoming more widespread, but not so many. It is not only the participants but also the operators. Therefore, the management side also has little know-how, and the number of power supplies at the hackathon venue is insufficient. Wifi goes down and development does not proceed. That is also a good deal. Therefore, in order to develop smoothly, we want at least a power strip. If you also have portable Wifi, it will be fail-safe.

I think we will start small and pivot

When I make a product in a hackathon, I really want to make something amazing, but it's quite difficult. Therefore, I think it is easier to narrow down the concept and simply aim to break through one function. However, its function often does not work well. Therefore, it is advisable to consider the 2nd and 3rd plans to some extent so that failover can be performed.

Avoid hackathons to build teams on the day

** This is my personal opinion, but I think that the hackathon that team builds on the day has a strong luck factor, and even if you are accustomed to the hackathon, it will be difficult. ** Not recommended, especially for beginners and first-time participants. Whether you assign a task to the other party or receive a task from the other party, you cannot determine the point of deterioration of the final product quality unless each other's abilities are clear. Therefore, in the case of a quick-build team, the members may refrain from each other and the product may not have much function, or the opinions of each other may conflict and the start of the product may not start at all. Personally, I need about 3 or 4 core members who are close and can exchange opinions frankly, and if you keep down the app engineer, backend engineer, and designer, you can enjoy the hackathon with confidence. I will.

Even if I see a product that doesn't work, it doesn't touch my heart

Avoid "I tried to do it, but it wasn't completed." And "I was planning to do it." Depending on the form of the hackathon, after the contest is over, some products will be exhibited and enjoyed by the general public. What do the general public who come to such an event expect to come to the event? Perhaps many people want to experience "I can make something like this in a short period of time! It's amazing!" "I've never seen such a service!" "Technology is interesting!" If the product does not work in such a case, it will give a very disappointing feeling. I think that is probably the case with the hackathon operators and judges. ** Move at least enough to demo. ** is my personal opinion.

Summary

--Let's make a product that works with a hackathon --Prepare in advance to make a hackathon-powered product --Think of an architect to withstand sudden spec changes in the hackathon

We talked about technical issues in this article, but there are other hackathon know-how that you should know to some extent. You don't have to keep this, but if you know it, you can enjoy participating in the hackathon. ** The best learning is to participate in a hackathon. Enjoy the hackathon! Let's Hack Time! !! ** **

[DOCKER] It's okay to participate for the first time! A hackathon starter kit that you want to prepare "before" participating in the hackathon!