Essential tools and resources for React Native developers

fabian-grohs-423591-unsplash.jpg

When you get started using React Native, the upside is that there are many community tools and material on the internet. The downside is also that there are so many community tools and material on the internet, that you can easily get lost.

It can be hard to find tools to debug or profile how the app is working. Community UI components can come in varying degrees of quality. Some components work but are not up-to-date with the framework. Browsing through tools on the internet can take time and not end up fixing the issue at hand.

This short guide will highlight some essential tools that should be the first recourse for developers beginning to use React Native.

Basics

React Native docs and GitHub issues: the official documentation is the number one resource to start with, but also the GitHub repository is useful to read release notes (and there are quite often new releases). It is also useful to search through the issues and see if your issue has already been experienced by other people.

React docs: when building React Native apps, you'll be writing React components and it's useful to refer to its official documentation sometimes to learn to properly use lifecycle hooks, performance optimization, and when modeling your application through props and state.

DevDocs: you can combine both React and React Native documentations together at DevDocs.io, a handy webapp with aggregated documentation. It also includes documentation for JavaScript, Node.js, npm, TypeScript, Babel, Flow, Redux, Jest, which you might want to see in one place. You can also customize it to show only the tools that you'll be using.

Expo: although it's not an official RN tool, Expo is probably the quickest way to get started when building a React Native app, so it's ideal for the initial stages of a project or when collaborating with a designer. It's handy to keep the Android Expo app or iOS Expo app installed on your phone, as well as use Expo Snack (code an app in the browser!) for quick experimentations.

Community resources

React Native Navigation: the topic of navigation (managing the state and transitions between screens in your app) has been sometimes officially supported in the framework, but it has had better solutions in the community as well. Nowadays the framework still has some navigation-related components, but the wise choice is to use either React Navigation or React Native Navigation (RNN). If you can afford the time to propely setup RNN by following its documentation, it will turn out to be the best navigation solution you can find out there, with good API, platform look and feel, and responsive performance.

JS.coach: there are so many community components for React Native, that it becomes useful to have a curated list of components, with an easy way of detecting whether they support Android or iOS or both. JS.coach is such list, with a search field and sub-categories in React Native.

Awesome React Native: an alternative curated list is awesome-react-native which includes components, but also native modules, utilities, example open source projects, blog posts, conferences, etc. Search here before searching on the wild web.

Debugging and profiling

log-ios and log-android: in Web Development we are used to opening the browser's console to view debugging information. For React Native apps, you can also open the browser (shaking the device, then starting "Remote JS Debugging") to view the console. However, some logging information related to the native app is outside of JavaScript, and in those cases running react-native log-ios or react-native log-android can help. For Android, you can run just adb logcat and it will show logs on everything happening in the device, not only in your app. Read more about debugging tools in the docs.

React Devtools: you can inspect the hierarchy of UI components with React Devtools which works for both React (web) and React Native.

systrace: for profiling performance in Android applications, systrace is a tool (in the Android SDK) not so familiar to many developers, but essential. It has a rather inconvenient way of using, but once you gather profiling data, it shows a lot of important important that helps you improve the performance of your app. Read more about React Native profiling in the docs.

Learning material

Conference videos: React Native is a constantly evolving framework, and some of its internals are still not documented, so sometimes React Native conference videos (from e.g. React Native EU, ReactiveConf, Chain React) on YouTube can help gaining insight.

Egghead courses: sometimes you may want a video course where another developer guides you step-by-step in creating a real world app, so Egghead has a couple of these courses. Some of them are specific to topic, for instance, animations. You may find free videos also on YouTube, of various quality levels.

People to follow: some people in the community are influential and often send out news about the framework. Eric Vicenti is a React Native core team member at Facebook. Brent Vatne is the main developer for Expo, and overall is involved with React Native. Leland Richardson works at Airbnb with large React Native projects, and authors some libraries. Mike Grabowski is a member of React Native core team and runs a company specialized in React Native, as well as running React Native EU conferences. Emil Sjölander works on the native side (C) of React Native, Yoga. Martin Konicek previously worked on React Native internals, e.g. the bridge and often still shares some knowledge about React Native.

That should cover most of what you need to know when developing mobile apps with this framework!

6 reasons to learn React Native

React Native was created in 2015 by Facebook developers as a framework to build sophisticated mobile apps using JavaScript and React (a web framework). When it was released, it was seen as either revolutionary or naive, because so far JavaScript had been a poor choice for developing mobile apps. Today, some 3 years later, the framework and the community around have grown mature enough that it's easily a good choice for professional development of apps for Android and iOS. Let's see a couple of reasons why.

Modern way to build a mobile app

Typically, to create a mobile app, first you must make a decision between the two dominating platforms: Android or iOS. That choice will affect the tools to use, since these two platforms have entirely different software development kits (SDKs). The tooling sometimes takes minutes or hours to download and setup. After that, the first app template takes a minute to compile. Only then, will you see an app on the device and can start programming, that is, if you have learned the languages (Java for Android, ObjectiveC or Swift for iOS) and their development kits. Once you make a code change, the app needs to be recompiled. These SDKs follow an old style of application development.

With React Native, the development workflow is closer to web development. First of all, you don't need to make a choice between one platform or another. Whichever you choose, you'll download the same tools to begin with.

Then, when running one command in the terminal,create-react-native-app you will have an initial project to work on. Install it on the device, and after that you can reload the app in the same way you can reload a website, leading to shorter development cycles. This way, React Native has reinvented mobile development to be modern like web development.

JavaScript is the world's most commonly known programming language among developers, and it's the language used to develop apps in React Native. While ObjectiveC and Swift can be nice languages with interesting properties, they are outside of the comfort zone of many programmers.

Other frameworks on the same level as React Native, such as Xamarin and Flutter, utilize different and less popular languages, respectively: C# and Dart. Hence React Native is has unique qualities when it comes to popularity.

Not only is the language popular, but also the library for UI components, React, has been growing to become the most commonly known web framework. Both JavaScript and React are comfort zone technologies for a majority of programmers today.

Real native user interfaces

There are other JavaScript frameworks to build mobile apps, such as Apache Cordova and tools built on top of Cordova. These are also known as "hybrid mobile apps" frameworks, because they produce apps that are basically small websites ("WebViews") packaged as if they were actual apps. The result is not always a great user experience, even though the apps are convincing and can be used in practice.

React Native takes a different approach. The resulting apps have UI components built with the platform's official SDK, but orchestrated behind the scenes with JavaScript. This means there are no WebViews involved, and the user often cannot recognize the difference between a React Native app and one built with the platform's SDK, leading to better user experience.

Cross platform

Since JavaScript controls native Android and iOS UI components behind the scenes, it's possible for a JavaScript React component to be supported by both platforms. This gives developers some possibility to reuse code.

The framework focuses on "learn once, write everywhere", though, because not all UI components should be exactly the same for both platforms. For instance, Android and iOS have different design guidelines, which means often one Android UI component should not exist in iOS.

That said, many components can have the same look and feel on both platforms, and that's how React Native allows those to be coded just once. The convenience of using one codebase and one framework for building apps for two platforms saves development time.

Share code from browser or server

There are many frameworks that allow cross platform app development, but few that allow you to take snippets of browser code or server code and include that in the mobile app.

Since JavaScript runs in the browser and on servers (Node.js), there are thousands of libraries from npm that could be reused from one context to another. Some libraries don't make any assumption about the context they are running in, for instance, Date libraries such as Moment.js. Those could be easily utilized in the browser, in the server, and in React Native apps. This kind of universal usage of libraries is an exciting benefit of React Native.

Not a lock-in

React Native is open source (MIT license), but it's also important that it doesn't lock you into this choice in the long run. You can choose to develop only one screen of your app using React Native, while the other screens are built with the official SDKs. Or, you can develop all screens in React Native, or anything in between. It allows itself to be partially used in the project.

This creates a path for migrating away from React Native if you so wish in the future, or creates a path for you to migrate an existing app to React Native. That kind of flexibility is important for business and managers to allow developers to evolve the codebase while minimizing risk.


If you want to learn more about React Native, and how to actually start coding with it, be sure to participate in our Code in the Woods training to be held on 21st and 22nd of April. Welcome!

Viime vuoden Code in the Woodsin tunnelmia

English version

Code in the Woods oli yksi viime vuoden kohokohdistani. Oli mukavaa kerrankin päästä työskentelemään saman ryhmän kanssa useampi päivä putkeen, saman aiheen äärellä. Kiireetön ilmapiiri auttoi puhumaan ongelmista ja vapaa-ajan aktiviteetit vapauttivat kilpailuintoa.

Konkreettisimmat asiat joita opin, oli miten gitin feature brancheja käytetään tiimiprojektissa ja miten tärkeää luottavainen ilmapiiri on ryhmän tehokkaan työskentelyn kannalta. Sillä on suuri vaikutus, että osoittaa olevansa aidosti kiinnostunut siitä, mitä toinen tekee. Verkon välityksellä tämä ei oikein onnistu. Yliopistolla tulee usein tehtyä ryhmätöitä etänä tai siihen varataan liian vähän aikaa, jolloin vuorovaikutus jää melko ohueksi. Code in the Woodsin jälkeen olen panostanut lähityöskentelyyn enemmän.

Ennen leiriä pelkäsin, että minulla ei ole aikaa mennä sinne. Ajattelin kuitenkin, että tässä on loistava tilaisuus päästä juttelemaan alan asiantuntijoiden kanssa siitä, että millaisia taitoja työelämässä oikeasti tarvitaan. Rekrymessujen ständeillä tunnelma on aivan liian jännittynyt hiljaisen tiedon kaivamiseen. Pääsinkin nyt ensimmäistä kertaa alan töihin.

Code in the Woods auttoi minua ymmärtämään, että työntekijältä tarvitaan kolmea erilaista taitoa: sosiaalisia taitoja, halua ymmärtää asioita syvällisesti, sekä kykyä saada asioita aikaan.

Hyvillä sosiaalisilla taidoilla viittaan siihen, että on sellainen ihminen, jonka kanssa on mukava olla päivittäin. Ei tarvitse olla porukan puheliain ja menevin, mutta se, että ei ole jatkuvasti ärsyttävä tai inhottava on tärkeää.

Asioiden syvällinen ymmärrys mahdollistaa laadukkaan koodin tuottamisen. Pelkkä reippaasti eteenpäin roiskiminen ei riitä, jos on tarkoitus tehdä sellaista jälkeä, josta muut voivat myöhemmin jatkaa.

Toisaalta perfektionismi voi haitata työskentelyä. Hyvä työntekijä ymmärtää, mitkä ovat niitä yksityiskohtia, jotka kannattaa tehdä kunnolla.

Uskon että nämä kolme piirrettä pätevät kaikkeen muuhunkiin luovaan työskentelyyn, eivätkä pelkästään ohjelmointiin.

Oliko kokonaisen viikon mittaiselle leirille meneminen hyvä idea kaiken kiireen keskellä? Ainakin käteen jäi arvokkaita työskentelytaitoja, kourallinen kavereita ja varma olo muiden kanssa ohjelmoimisesta.

 

Felix Bade, 

Code in the Woods Junior Camp 2017

SECOND BADGE OF PWA DEVELOPERS

 

 

From the setting steams of Code in the Woods junior camp there raised excitement and demand for more. Senior developers with exciting and varied backgrounds reached for us and asked for a senior spinoff and we took the challenge. Barona Technologies and Forenom came together again to work side by side, successfully.

For two rainy Saturdays passionate professionals gathered together around the questions of Progressive Web Application. With the help of talented Petri Louhelainen, our teams built their own web based solutions and improvements on top of YLE APIs.

23715319_10213214444347971_1800213732_o.jpg

Since Google's release of PWA just two years ago, it has slowly but surely gained more interest in growing developer communities. Now in 2017 we can truly say it is one of the most interesting and functional discoveries in the world of application development. This was clearly seen at Code in the Woods as well. The level of enthusiasm towards learning and finally mastering the basics PWA was just admiring and we can truly say those Saturdays spent coding were definitely worth the hours.

Now after Code in the Woods junior camp and a two-day senior sprint we can proudly say there are now a few handful of new developers set in the right path of Application development.

Now after Code in the Woods junior camp and a two-day senior sprint we can proudly say there are now a few handful of new developers set in the right path of Application development. What’s the next top new technology to master? Stay in tune for 2018 and stay in the front wave of programming.

 

Rosa Smolander

Code in the Woods -coordinator

codeinthewood_sticker-01.png
 

RAJAPINNOISSA ON VOIMAA!

 

 

Suomessa sähkön jakelujännite on standardoitu 230 volttiin (standardi SFS-EN 50160). Samoin pistoke ja sen vastakappale on standardoitu (SFS 5805). LVI-puolellakin standardien lista on pitkä: yhtenä esimerkkinä hanat ja putket (SFS-EN 817). Kuluttajalle ja käyttäjälle on kätevää, että kaupasta ostetun riippuvalaisimen voi itse kytkeä paikoilleen ja käsisuihkun voi itse vaihtaa ongelmitta. Edellä mainitut esimerkit ovat fyysisten rajapintojen standardeja. Ne tuovat ihmisten arkeen monia hyötyjä. Yhteisistä standardeista on myös kansantaloudellisesti järkeä, koska ne pakottavat valmistajat kilpaileman tuotteiden paremmuudella, ei rakentamaan suljettuja ekosysteemejä ja monopoleja tai kartelleja. 

Olemme kehittäneet omaa Salaxy-sovellustamme nyt useamman vuoden ja lähtökohtana meillä oli alusta alkaen pitäytyä standardeissa ja toteuttaa sovellusta API-vetoisesti. Itsestään selvien internetin perusstandardien lisäksi (esim. HTTPS, JSON, REST), olemme toteuttaneet menestyksekkäästi mm. OAuth2 2.0 -standardin ja OpenAPI 2.0 –standardin. OAuth 2.0 antaa mahdollisuuden sekä omille tuotteillemme että muille rajapintaamme hyödyntäville käyttää valmiita kolmansien osapuolien komponentteja tai kirjastoja OAuth 2.0 -pohjaiseen autentikointiin. Käytännön sovelluskehitystyöhön tämä tuo nopeutta ja laatua. OpenAPI 2.0 puolestaan takaa sen, että pystymme toteuttamaan sovellusten käyttöliittymät käytännössä millä tahansa relevantilla kielellä tai frameworkilla julkaisemaamme API:a vasten. 

Standardit ja sovellusrajapinnat (API) ovat olennainen osa omaa sovelluksen suunnitteluprosessiamme. ”Onko tähän tarkoitukseen soveltuvaa standardia jo kehitetty?”, ”Onko kyseinen standardi jo tullut voimaan, ketkä muut sitä toteuttavat?” ja ”Miten tämä toiminnallisuus julkaistaan API:na?”. Nämä ovat meillä tyypillisiä kysymyksiä ja yhteisen pohdinnan käynnistäjiä. 

Standardeihin on pakattu valtava määrä aivotyötä jo valmiiksi ja sen takia niitä kannattaa tutkia, vaikka ei aina kaikkea itse toteuttaisikaan.

Standardeihin on pakattu valtava määrä aivotyötä jo valmiiksi ja sen takia niitä kannattaa tutkia, vaikka ei aina kaikkea itse toteuttaisikaan. Oman API:n rakentaminen on meille tärkeää luonnollisesti oman liiketoimintamme näkökulmasta, mutta myös siksi, että se auttaa meitä kehitystyön organisoinnissa. Käytännössä voimme jakaa työtä monelle taholle ja yhdistävänä tekijänä on dokumentoitu API. Näin esimerkiksi käyttöliittymätiimi voi tehdä työtään olematta jatkuvasti riippuvainen taustajärjestelmää kehittävästä tiimistä. Lisäksi työ voidaan vielä jakaa sekä käyttöliittymän että taustajärjestelmän puolella pienempiin osiin API:n toiminnallisten kokonaisuuksien avulla. 

Oma kokemukseni on, että rakensit sitten taloa tai palkanmaksuoperaattoria, niin toteutuksen lähtökohdaksi kannattaa ottaa olemassa olevat standardit ja API:t. Ne auttavat myös jakamaan laajankin kokonaisuuden ja työmäärän mielekkäisiin sekä helpommin hallittaviin osiin. 

salaxy_135_Olli.jpg

Pyörää ei kannata keksiä joka kerta uudestaan, vaan rakentaa uutta jo koeteltuja ja hyväksi tiedettyjä standardeja hyödyntäen. Hälytyskellojen pitää soida viimeistään siinä vaiheessa, kun kiinnität lampun johtoja kattoon jeesusteipillä ja sokeripalalla – tai huomaat tekeväsi käyttöliittymää suoraan taustajärjestelmää vasten! 

 

Olli Perttilä 

Co-Founder & CTO Salaxy.com

 

BYEBYE WOODS, FOR NOW

 

 

Code in the Woods Day 5 - Retro

 

Viikon viettäminen metsässä yksin tuntemattomien kanssa on pelottava ja rohkea päätös keneltä tahansa, saati sitten itsenäiseen työskentelyyn tottuneelta varhaisemman vaiheen koodarilta. Asut viikon poissa mukavuusalueeltasi, pysäytät oman elämäsi ja työsi kotipaikkakunnallasi viikoksi ja tarkka sijaintisi Etelä-Suomen kartalla on tuntematon. Hakemuksia kuitenkin satoi tähän yllätyhulluun ohjelmaan mieletön määrä ja kartanoon valikoitui uskomaton porukka, jonka kanssa lähtöasetelmat yhteiseen viikkoon olivat kohdillaan.

20171019_173231(0).jpg

Tämä uskomaton viikko on nyt monen hienon hetken jälkeen takana ja koko tiimi osallistujista, mentoreihin ja ohjelman rakentajaan Lauri Svaniin jättää minut ilosta sanattomaksi. On ainutlaatuinen etuoikeus saada todistaa sitä omistautumista, intohimoa ja lämpöä, jolla nuoret osaajamme ovat työskennelleet. Kuten osallistujamme Teemu sanoikin, 6 viikon opintojakson työ on tiivistetty 4 päivään. Ja, mikä parasta, tiimimme selvisivät siitä ja demot saatiin ulos, älytöntä!

DMky_XLXcAI82e7.jpg-large.jpg

Code in the Woods ei jäänyt tavalliseksi koodaustapahtumaksi. Sulkiessani viimeisenä kartanon oven, joka oli viikon ajan toiminut kotinamme, saatoin varmuudella sano, että me olemme muodostaneet pienen Woods -perheen. Yhteisön, joka on täynnä ystävyyttä, vertaistukea, mentorointia, saunomista, naurua, väsyneitä tunteja ja toivottavasti monia yhteisiä ohjelmointi- ja oluthetkiä myös jatkossakin.

 

 

Rosa Smolander,

Code in the Woods koordinaattori, Barona Technologies

20171020_114319.jpg
 

 

4 PÄIVÄÄ

4 TIIMIÄ          

4 DEMOA

 

Code in the Woods Day 4 - Demonight

 

80 tuntia, 7 kahvipakettia, 90 teepussia ja 3 enemmän tai vähemmän nukuttua yötä myöhemmin Code in the Woods kartanossa on syntynyt 4 verkkopohjaista applikaatiota, 20 uutta ysävyyssuhdetta, 4 kovaa ohjelmointitiimiä ja yksi yhteinen perhe.

Viikko on ollut haastava jokaiselle tiimille lähtötasoa katsomatta. Moderni teknologia on kaikille uutta, eteentulevat esteet yllätyksellisiä ja aika ohjelmointiin on varsin rajattua. Tästä kaikesta huolimatta jokainen tiimeistä onnistui mahdottomalta tuntuneessa haasteessa. Kaikki saivat demot ulos! Tässä pientä tuntumaa siitä, mitä tiimit YLE Appiksista muotoilivat:

1. Ylen anti

Kova Code in the Woods tiimi Ylen Anti helpotti käyttäjän turhautumista pätkivään nettiyhteyteen. Tiimi rakeni Le Off -applikaation, joka lataa toivotun videomateriaalin käyttäjän laitteelle sekunneissa ja Pasila-jaksoja voidaan nyt katsoa ilman nettiä niin lentokoneissa kuin junissakin. Samalla selvisivät myös viikon mystiset nettikaistan kaappajat.

DSC_0528.JPG

2. CatCycle

Tiimi CatCycle omien sanojensa mukaan on tehostanut kissavideoiden katsomisen. Applikaatio ajoittaa videon katselun aikana klikatut tykkäykset oikeaan kohtaan videota niin, että katsojan nautittavaksi jäävät vain niiden parhaat palat. Alapeukutetut pätkät voi skipata suosiolla. Tästä löytyy potentiaalia Vine complitation-tuotannon automatisointiin!

DSC_0525.JPG

 

3. Fiilis

Fiiliksen demoon pääsivät kaikki osallistujat mukaan. Fiilis sosialisoi TV:n katsomisen etäisyyksien yli ohjelmaa reaaliaikaisesti seuraavalla chattipalvelullaan. Applikaatiossa saman ohjelman fiilistely onnistuu vaikka koko suvun kesken mobiilin välityksellä.

 

4. Leffalegendat

Leffalegendat taas yhdistivät valtavat elokuvakirjastot ja YLE Areenan sisällöt. Aapplikaation avulla unohtuneet Tauno Palon klassikot ja vanhat venäläiset scifielokuvat löytyvät vaikka pelkän tunnusmusiikin tai pelkistettyjen hakusanojen nimillä.

DSC_0518.JPG

Lyhyenä aikana ja uusilla teknologioilla tuotetut työt olivat valtavan, mutta onnistuneen puserruksen takana. Ilta päättyi hyvin ansaitusti pikkutunneille juhlittaessa paljun, saunan ja grillin siivittämänä. Onnistumisen ilo ja yhteisön hyvä fiilis oli käsinkosketeltava ja loistava päätös yhteiselle työlle.

 

 

Rosa Smolander,

Code in the Woods koordinaattori,  Barona Technologies

DSC_0508.JPG
 

HEI ME KOODATAAN!

 

 

Code in the Woods Day 3 - Prototype

 

UX-suunnitteluntäyteisen tiistain jälkeen Code in the Woods tiimit pääsivät vihdoin koodaamaan täyttä häkää. Aamulla pohjatiedoiksi otettiin selainkehityksen knoppeja ja API-koodausta, jonka jälkeen tiimit lähtivät toteuttamaan kukin omia projektejaan. Tiimien fiiliksiä kysyttäessä yleisin vastaus meni jotakuinkin näin: “Yllättävän hyvin menee!” Tähän löytyi montakin syytä, joista osa oli tullut monelle tiimille uutena. Tässä muutamat päivän aikana esiin tulleet opit yhdestä kuuteen:

1. Tiedä mitä teet.

Kahden edellispäivän aikana tiimit ovat paitsi huolehtineet ympäristöt ja muut perusasiat kuntoon, myös kristallisoineet ja luonnostelleet ideansa sekä suunnitelleet sen ensimmäisen version varsin tiivistunnelmaisessa designsessiossa. Lisäksi tiimit olivat jakaneet tehtäviä taskeihin ja priorisoineet niitä toimivaan päivän työstöjärjestykseen. Kun tehtävät ovat tiedossa, ei tarvitse jäädä arpomaan mitä tehdä.

“Meillä on tässä hyvin yksinkertainen versio pääideasta: käyttäjä voi reagoida tiettyyn kohtaan videota”. -Code in the Woods tiimi Niina, Tunde, Jami ja Felix

Image uploaded from iOS.jpg

2. Käytä valmiita sapluunoita.

Hyvä pohjatyö auttaa muutenkin: kun API on tiedossa ja dokumentoitu, softalle löytyy pohja ja työkalut valmiina, käyntiin pääsee nopeasti.

Aika harvoin projektia kannattaa aloittaa täysin nollista. Useimmilla frameworkeillä on oma “Hello world”-starttipakettinsa, jossa tärkeimmät riippuvuudet ovat valmiina ja rakenne noudattaa sovittuja konventioita. Se helpottaa paitsi aloittamista myös useamman ihmisen tekemistä: konventiot niin nimeämisessä kuin hakemistorakenteessakin helpottavat tekemistä.

3. Jätä toisto koneelle - buildityökalu on painonsa arvoista kultaa

Ensimmäisiä projekteja yksin tehdessä Gulpin kaltaiset buildinhallintatyökalut voivat tuntua turhanpäiväisiltä. Eikös tämän saman homman saa tehtyä skriptillä suoraan komentoriviltä?

Ongelmia alkaa kuitenkin tulla, kun scope kasvaa ja halutaan tehdä myös kunnolla. Skriptirivi kasvaa pituutta, sitä pitää muokata eri käyttötapauksia varten, tai softan käynnistys alkaa vaatia useamman rivin ja alat pohtia käynnistysloitsujen siirtoa omaan shelliskriptiinsä.

Haluat ehkä että javascriptit kerätään build-tiedostoonsa, ja ne kerätään kuvien kera dist-hakemistoon. Kehityksessä halutaan ehkä käyttää eri rajapintoja kuin julkaistavassa versiossa. Softalle halutaan ajaa linttiä tai minimoida tai obfuskoida javascript-filet.

Tässä työkaluksi apuun tulee buildityökalu. Niitä on monenlaisia ja moneen lähtöön, mutta yhteistä on, että ne huolehtivat riippuvuuksista, käynnistämisestä ja monista pienemimistä tehtävistä. Niitä voi myös yhdistää toisiinsa. Buildityökalut ovat alan standardi ja useimmat ammattilaiset muistavat (tai käyttävät edelleen) esimerkiksi Makefilea, joka on ollut C++-ohjelmien de facto buildityökau. Grunt ja sittemmin Gulp ovat vallanneet sijaa Javascript-maailmassa. Työkaluissa kestää toki hetki oppia, mutta se on sen väärti

4. Pidä koodi siistinä - lintteri

Kaksi vai neljä merkkiä indentaatiota? Koodarien ikuisuustaistelu on välillä turhauttava, mutta silläki on merkityksensä: koodin on syytä näyttää yhtenäiseltä jotta sitä on helppo lukea ja muuttaa. Lintteri voi tarkistaa sisennykset, mutta se tekee paljon muutakin: tarkistaa nimeämiskäytäntöjä, varoittaa mahdollisista sudenkuopista ja auttaa tiimiä noudattamaa kovaa kuria. Äitisi ei siivoa täällä, joudut itse tekemään sen.

5. “Gitti on kova” - Käytä versionhallintaa!

Neljänkin hengen projekti alkaa mennä mahdottomaksi ilman versionhallintaa. Oivallus onkin, miten paljon helpompaa koodia on jakaa isommallakin porukalla kun merget ja diffit hoitaa kone, ei yksi tiimin jäsen silmät ristissä ;)

6. Käytä työkaluja myös projektinhallintaan

Joskus post-it riittää, mutta esim. Trello on hyvä ja yksinkertainen työkalu todo-listan hallintaan ja priorisoitiin. Muista tehdä valmiita, julkaistavia kokonaisuuksia.

Tätä kirjoittaessa ulkona on pimeää ja sisällä valoa tulee paristakymmenestä läppärin ruudusta. MVP on monella lähelle valmista: softa ei näytä vielä kovin hyväoltä mutta ainakin jokin päätoiminnallisuus on jo valmiina. Tekeminen jatkuu myöhään yöhön ja huomenna päästään viimeistelemään.

 

Kirsi Louhelainen,

Code in the Woods mentori, Barona Technologies