Tekkisessio React Nativesta

Tekkisessio React Nativesta

Perjantain tekkisessiot on yksi parhaista jutuista Wunderdogilla. Tekkisessio on tunnin pituinen esitys mistä tahansa aiheesta, jonka kokee jakamisen arvoiseksi. Kynnys on matala ja innostus korkealla. Vedin viime viikolla session React Nativesta, Facebookin projektista, jossa tehdään Javascriptillä natiivisovelluksia iOSille ja Androidille.
 

Reactissa käyttöliittymiä rakennetaan kirjoittamalla Javascriptillä erilaisia komponentteja, joita käyttäen voidaan tehdä React Nativella mobiilisovelluksia. Facebookin blogipostaus avaa taustoja laajemmin, mutta pitkään ongelmana oli se, että Androidin sovellukset tehdään Javalla ja iOSin sovellukset joko Objective-C:llä tai Swiftillä. React Nativella saadaan molemmat versiot samalla koodilla.

 

React Native on edelleen melko tuore, mutta npm:stä löytyy jo 3878 pakettia hakusanoilla React Native ja Stack Overflowssa on vilkas yhteisö. Wunderdogit ovat olleet mukana kahdeksassa React Native -projektissa, joten tukea löytyy myös omasta laumasta.

 

Parasta React Nativessa on, että samalla koodilla saa tehtyä sekä iOS- että Android-sovellukset. Eri komponenteista on myös helppo luoda omat versiot Androidille ja iOSille. Jos valmista React Native -komponenttia ei löydy, voidaan käyttää eri kirjastoja iOS- ja Android-toteutuksiin, mutta usein se ei ole tarpeen. Käytössä ovat myös eri alustojen natiivikirjastot, joiden tuominen React Nativen käyttöön on melko vaivatonta. Käytännössä alustakohtaista koodia tarvitaan kuitenkin lähinnä komponenttien tyylittelemiseen.

 

Tilan hallinta on React-maailmasta tuttu ongelma, jota usein ratkaistaan Reduxilla. Sitä käytetään myös React Nativessa, mutta myös paikallinen tilanhallinta on käytössä. Mobiilisovelluksissa on usein yksinkertaisia näkymiä, jotka tekevät vain yhden asian, jolloin eri komponenttien ei tarvitse olla niin tietoisia toisistaan ja niiden tilanmuutoksista.

 

Dogeilla oli kaksi suositusta debuggaukseen. Toiset käyttävät Android Debug Bridgeä ja Xcoden konsolia ja toiset Remote JS Debuggingia selaimessa. Molemmat ovat kivoja vaihtoehtoja ja ne saa valmiina React Nativesta.

Tekkisession keskusteluissa selvisi, että React Nativea on testattu monella eri tavalla. Osa rekuista suosii Jestiä ja osa tekee Mochalla ja Enzymellä. Käytännössä helpointa lienee yksittäisten komponenttien testaaminen erikseen, sillä React-komponentteja voi renderöidä Enzymellä ja varmistaa niiden toiminta testeillä. Jestin tapauksessa UI:sta otetaan snapshotit talteen ja Jest huomauttaa, jos koodimuutokset muuttavat komponentteja. Kukaan ei ollut tehnyt testejä simulaattoreita käyttäen johtuen varmaankin siitä, että Xcoden simulaattoritestit kirjoitetaan Swiftillä tai Objective-C:llä ja koko React Nativen pointti on, ettei näitä kieliä tarvitse hallita täydellisesti.


Keskustelun jälkeen pääsin kokeilemaan koodaamista livenä ensimmäistä kertaa. On mielettömän siistiä, kun joku koodaa yleisön edessä vaikkapa Helsinki JS:ssä, mutta en ole aiemmin itse kokeillut sitä. Tekkisession paras puoli onkin, että tutun yleisön edessä on turvallista kokeilla uusia asioita ja kasvaa esiintyjänä. Otettiin käyttöön react-native-sketch kirjasto tarkoituksena näyttää, miten nopeasti React Nativella saa laitteella ajettavaa softaa.

 

Yleisön edessä koodatessa hommat eivät tietenkään onnistu samaan tapaan kuin kotona, mutta luulen silti että esityksestä oli hyötyä. Valittua komponenttia ei oltu vielä päivitetty toimimaan uusimmalla React Nativen versiolla ja issueista piti löytää sopiva branchi ajoon. Testiprojektin poistaminen Xcodesta ei poistanutkaan tiedostoja ja Code Signing ei tietenkään onnistunut, mutta Appi saatiin ajoon simulaattorilla.

 

Voin kyllä varauksetta suositella React Nativea. Apua on tarjolla runsaasti ja Javascriptillä saa paljon aikaan nopeasti. Tiimi pääsee iteroimaan heti, kun näkymiä voidaan tehdä vauhdikkaasti ja versioita voidaan kätevästi jakaa TestFlightin avulla.

 

- elsa

Bots here, bots there, bots everywhere -  Potential Use Cases for 2017

Bots here, bots there, bots everywhere - Potential Use Cases for 2017

Facebook launched the Messenger platform for bots less than a year ago. Since then, there are reportedly over 34,000 bots for the platform. Number seems small compared to platforms from Asian markets, such as WeChat and Kik. Many consider bots as the new apps. It’s no wonder. An average (US) smartphone user won’t download any new apps on their device, and the majority uses only 4-5 apps actively. Unsurprisingly them being messaging apps, such as WhatsApp, Messenger, Facebook and Instagram.

Thus it's rather safe to assume the future is not in apps per say, but in a new form of consuming content, may it be through chat bots. Here are a few ideas what we might see from bots in the year to come.


Structure over conversation


Bots + AI = Jarvis-like personal assistant? I don’t think so. At least not in the near future. While natural language processing might already be good enough for some use cases, bots in 2017 will follow more traditional user flow, rather than mimic conversations. When interacting with the bot, the user will be given options rather than open-ended questions. This way the user will have a better understanding of what to expect. For example, you can get and view your travel itinerary, buy stuff and track your deliveries, or check the current weather on Messenger with a bot.

Bottom line: Chat is, for the time being, a streamlined interface to execute simple tasks that you have dedicated apps for.
 

Kill time


Facebook launched instant games on Messenger in November 2016. Are you chatting with someone and waiting for them to reply? Taking your time in the loo? Bored in a queue? Open Messenger and play a round of Pac-Man or Space Invaders. You don’t have to download anything. Simply search for the game on Messenger and start playing.

Bottom line: Like Android instant apps, you can access content without downloading anything on your device.


Hybrid Customer Service


This was one of the initial trends. Automating simple customer requests and bringing in humans only for more complicated cases. Does this sound familiar? Everyone of us has dialled a service line that asked you press number on a keypad depending on your query. As the humankind is getting more introverted, we tend to prefer texting/emailing over talking. Expect your wireless operator to provide customer service through chat platforms. By leveraging chat bots, customer service can reduce waiting time and allowing customer reps to focus on more complex issues.
For example, connect your Amex to Messenger and you’ll get notified every time your card is used. Twitter is allowing brands to give automated replies when you ask certain questions in DM.

Bottom line: Let your customer reps to focus on complex issues, while automating simple requests.


Discover


The cherry on top! My personal favourite. What is the main function of Facebook, Twitter, Foursquare or even Google? For me it is staying on top of things and discovering new content. Expect more brands to use bots to help consumers discover new services and content.
For example, get news headlines daily to your favourite messaging platform. I use Wired and TechCrunch bots on Messenger daily. Fancy a trip? Ask Hipmunk assistant for travel and flight recommendations.

Bottom line: Finding and using new services will become easier using the messaging services you already use every day.


Building bots


The best part of the bot ecosystem is that anyone can build simple bots without a single line of code. Since bot platforms, such as Kik, Messenger and Slack, allowed anyone to build bots on their platforms, we have seen an emergence of bot building tools like Chatfuel and Octaine AI.
Bottom line: Traditional gatekeepers for apps, App Store and Play Store, will be bypassed. App makers have a shorter time to market through chat platforms.


What do you think are the most suitable use cases for chat bots in 2017?

P.S. Be sure to check out our side project: LunchBob. Bob is a chat bot for Messenger that recommends places to have lunch near your location. We built it over a weekend in December to outsource our decision-making where to eat

Why should every developer care about monitoring

Why should every developer care about monitoring

"You can't control what you can't measure" -Tom DeMarco

 

Building a new digital service from scratch has never been easier. There are plenty of libraries, frameworks, platforms and service providers that make it possible to get our ideas into production in a matter of days if we push the envelope. We also have pretty good practices on how to develop software in general, accompanied with tooling and processes to deploy changes to production safely.

However, there is still a significant disconnect between development and operations regardless of all the DevOps buzz. Developers code, configure infrastructure and take care of the deployments. But then, there is the infamous someone who takes care of the operations and monitoring. I call this approach DevOpsBut, which might ring a bell for those familiar with ScrumBut.

 

Production should be every developer's primary concern

The harsh reality is that our code creates value only when it runs in production. Regardless of how well we implement and test our code, none of our development elegance can guarantee that our service runs smoothly in production. There are just too many moving pieces in the puzzle.

From a bookkeeping perspective, we can think of our codebase as a liability, and it can only be considered an asset when it is delivering business impact in production. Therefore having operable software should be every developer’s top concern.

Any non-trivial software system contains essential complexity which is inherent to the domain. There is no way around that. We also tend to be guilty of building some amounts of accidental complexity by our designs regardless of how hard we try to avoid it. With that said, the only way to be in control of such a complex system in production is to measure the key business metrics and have a close eye on them continuously.

 

What could possibly go wrong?

First, our customers can interact with our service in the most peculiar ways, which can lead to unexpected results and errors. Different end user devices, desktop and mobile browsers included, provide many browser quirks. There is no limit to the amount of manual exploratory testing to avoid this.

Second, it is possible that our user interface is too complicated, and our end users cannot get the desired actions done. In this case, everything is fine from a technical perspective - not a single trace of error anywhere, but neither are there any expected business transactions happening. Without business metric based monitoring we are happy while our customers are frustrated. How uncomfortable is that?

Third, software is turtles all the way down. For example, the downstream dependencies can become unavailable, or even worse, start responding slowly. Some parts of our core infrastructure might melt away for whatever reason. In a complex system, a small, innocent-looking anomaly can cause cascading failures, which might not seem interrelated. Due to concurrency, the sequence of events can be non-linear. These are scenarios that are close to impossible to foresee during development.

 

Optimize for Mean Time to Recovery

In general, there are two methods of quality assurance. One approach is to make sure there are no bugs introduced in the first place. We focus our efforts on carefully testing our systems before deploying to production. With this laborious approach, the frequency of bugs found is small. This is all about optimizing the mean time between failures, or MTBF. The goal is to minimize the number of bugs and maximize the time between outages, regardless of the cost.

Another approach is to make sure that whenever an anomaly happens in production, we know it in the very first second and have detailed diagnostic data. With a proper deployment pipeline in place, we can fix the problem quickly, and the impact of this failure is small in both scale and time. Such thinking optimizes the process for mean time to recovery, or MTTR. Bug count is not the primary concern. Instead, we make sure that we are aware of any exceptions within the first second and can fix them promptly.

My question now is that would you rather live with the illusion of having perfect codebase surrounded by an ideal environment, or having state of the art tools in place to inform you when the unexpected happens in production? To be the first one to know of any issues. Or in contrast to have customers report them. Which one of these approaches make you sleep better during nights? Since resources are limited and software is complex, I would try to minimize the mean time to recovery over maximizing mean time between failures.
 

 

It is time to start measuring outcomes

Monitoring merely technical data is better than nothing, but it will only get us halfway there. The next step is to start monitoring KPI’s in real time. For an online web store, this can be the amount of logged in users, signups, shopping cart checkouts or payments. When we have collected the baseline figures for these transactions, we can setup alerts which are triggered on unexpected drops or peaks in our service metrics. Now we know when our service is healthy from the business perspective as well.

By monitoring business transactions, we can start to measure the impact of our releases. It can be an incredible game changer in the way we develop software. Instead of focusing on output and features such as “customer can sign up using social login”, we can start to measure outcomes like “we get more customers signing up for our service.” Now we can optimize development efforts on business goals using data. It is a fundamentally different approach compared to prioritizing work based on the highest paid person’s opinion.

 

Towards Operations-Driven Development

Getting proper monitoring in place is a bit similar to a well-crafted test suite or application security. It is not easy to wire these on top of the application later. Things like elementary server monitoring and health checks are easier to achieve compared to going all the way with an MTTR-optimized development process.

Should developers focus on monitoring and stop writing automated tests? Of course not, that would be insane. There are numerous reasons for having a test suite in place. Tests are our safety net. They allow us to develop features faster, enforce modular design, and help in documenting system behavior.


Monitoring is our safety net in the most critical environment: production. Therefore, all developers should ensure that their applications are robust from an operations perspective as well. All we need is to add a bit of "operations-driven development" mentality to our daily development routines. But then how do we take care of all this in practice? Well, that is another story and another blog post.

Työmatkakoodaus - harrasteprojektien pelastus

Työmatkakoodaus - harrasteprojektien pelastus

"Jokela? Hetkinen, missäs se sijaitseekaan?" Tämä on tyypillinen kysymys, kun kerron työkavereilleni käyväni töissä hiukan kauempaa. Täytyy kestää iäisyys tulla moisesta perähikiästä Helsinkiin, ja vielä joka arkipäivä! Sepä se, mutta nyt kerronkin, miksi se on hieno asia.


Tiedämme kaikki, että pienemmällä prioriteetilla olevat projektit tuppaavat alkuinnostuksen jälkeen jäämään yhä harvenevien koodauskertojen vuoksi taka-alalle. Kun koodiin ei koske, se alkaa viiletä, ja uudelleen paneutuminen vaatiikin jo lyhkäisen mikrolämmityksen. Tämän vuoksi projekti alkaa yhä kylmetä, ja pian se siirtyykin jääkaappiin, pakastimeen, ja lopuksi ikiroutaan, josta ei lämminsydämisinkään koodari sitä enää sulata.


Ainoa oikea jäänestoaine on usein toistuva, säännöllinen naputtelu. Ja mikä olisikaan tähän prosessiin parempi implementaatio kuin joka arkipäivä kahdesti toistuva työmatkakoodaus!


Palataanpa reilu vuosi taaksepäin. Asuin tuolloin Helsingissä ja kävin töissä Helsingissä. Työmatka oli ajallisesti vain hiukan lyhempi kuin nykyään, mutta muuten toivoton: vaihtoja junasta metroon ja metrosta bussiin. Podcastit olivat ainoa pelastus, mutta ei Sarasvuon monologejakaan jaksa liian montaa kuunnella. Mikä tilanne on nyt susirajan takana asuessani? Kahden minuutin pyöräily asemalle, 37 minuuttia tiukkaa koodia tasaisessa junakyydissä, ja pari minuuttia kävelyä työpaikalle.


Matka menee kuin siivillä: hetkisen naputtelun jälkeen joudun jo harmittelemaan kun juna tulee perille ja kiinnostava koodinpyöritys jää kesken. Mutta ei huolta, seuraava työmatka koittaa pian! Jos juna myöhästelee, kuulen ympäriltäni tuskastuneita huokailuja, mutta itse myhäilen tyytyväisenä, saanhan ehkä featuren valmiiksi sittenkin jo tällä matkalla! Kun saavun varsinaiselle työpaikalleni, aivoni on jo lämmitelty ohjelmointivaihteelle, ja Gitin kolkuttelu voikin alkaa saman tien.


Voisi kuvitella, että junamatkasta tuhraantuu arvokkaita minuutteja kaikenlaiseen virittelyyn matkan alkaessa ja päättyessä. Mitä vielä! Kun tulen junaan, valitsen sen tutun optimaalisen ikkunapaikan, avaan koneen kannen, painan kännykästä hotspotin päälle ikkunalaudalle, ja IDE:ä ei edes tarvitse laittaa tulille - koodi odottaa heti kutsuvana nenäni edessä samassa kohtaa johon viimeksi jäin. Kun juna nytkähtää liikkeelle, on koodiviidakossa jo täysi kuhina päällä. Tasan 37 minuuttia myöhemmin kuuluu naps, kun sorvin kansi kolahtaa kiinni ja kävelen miltei odottamatta junan ovista ulos kohti rämää polkupyörääni.


Kun junassa välillä nostan katseeni kinkkisen bugin alhosta ja vilkaisen ulkomaailmaan, huomaan että kanssamatkustajanikaan tyhjän panttina ole. Lähes kaikilla on kätösissään kiiltävät älypuhelimet, joista luetaan, kuinka fasetuttu on päättänyt tiukan habatreenin ja on nyt suihkunraikkaana, tai kuinka "BB-Kimmon kääpiösnautserin ulkoilutus päättyi yllättävästi - lue lisää". No, toki näilläkin on paikkansa, ja muitakin vaihtoehtoja on. Enkä sano, että kytyiset harrastetunkkaukset olisivat arvokkaampia kuin edellä mainitut, mutta ylipäänsä jokin tavoitteellinen tekeminen saattaa olla kymmentä sekuntia pidemmällä tähtäimellä palkitsevampaa.


Jos työmatkani olisi vaikka vain viisi minuuttia, enkö voisi naputella samat koodit kotona? No, katsopa peiliin ja kysy käsi sydämellä, tulisiko tehtyä joka päivä. Vastaus: Ei. Vaihtoehtoisia askareita tulisi kummasti mieleen pitkä lista. Taitaisi olla aika epätoivoista myös yrittää kertoa puolisolle kotona, että "Koodasin juuri kahdeksan tuntia töissä, ja jatkan vielä tässä kotona puoli tuntia, hoidatko lasta".


Mielestäni eräs työmatkakoodauksen merkittävimmistä hyödyistä on se, kuinka alitajunnan saa valjastettua ongelmanratkaisuun. Kun kohtaat menomatkalla hankalan pähkinän, voit hetken miettimisen jälkeen siirtyä eri tehtävään, ja jättää ongelman ratkomisen alitajunnalle. Voi hyvinkin olla, että paluumatkalla ratkaisu on kirkkaana mielessä, tai viimeistään aamulla, aivojen raksutettua unessa töitä. Tällaisia etuja ei saisi, jos tekemisen ajoittaisi yhdeksi viikottaiseksi köntäksi. Kun lyhyet pätkät toistuvat usein, projektin tilanne ja koodi pysyy hyvin muistissa. Siihen on helppo palata.


Aivan kuin jokikin koostuu pienistä puroista, softakin koostuu koodinpätkistä. Kun päivät, viikot, kuukaudet kuluvat, huomaat yhtäkkiä katselevasi junakoodista kehrättyä, eksoottista softailmentymää. Commit-historia on pitkä kuin Tokmannin ämpärijono ja todistaa pitkäjänteisestä työstä, joka on kertynyt kuin huomaamatta.


Tänä syksynä olen paria poikkeusta lukuunottamatta koodannut joka ikisen työmatkan. Ainakin tähänastiseen työmatkakoodaukseeni olen kovin tyytyväinen; olen saanut edistettyä monia projekteja, pienoisena esimerkkinä eräs Wunderdogin koodauspähkinöistä. Jos koodausideat loppuvat, voin ottaa työn alle jotakin muuta pitkäjänteistä, vaikkapa Dostojevskin tuotannon. Vältynpähän ainakin päämäärättömältä kännykän näperrykseltä, jota jo muuten harrastan aivan riittävästi. Siispä: muuta sinäkin kauemmas!


P.S. Uusin Wunderpähkinä on julkaistu hiljattain! Olisiko sen ratkominen ensimmäinen #työmatkakoodaus sinulle?