Opettaja ideajahdissa Goforella

Olen vaikuttunut. Olen inspiroitunut. Näillä sanoilla kuvailen päättynyttä TET-harjoittelujaksoani Goforella.

Olen kokenut lukion opettaja. Kun minulle tarjoutui mahdollisuus lähteä tutustumaan nykypäivän työelämään yrityksessä, päätin tarttua tilaisuuteen heti. Ja mitä pääsinkään oppimaan! Olin TET-viikkoni aikana kuuntelijajäsenenä useissa palavereissa sekä keskustelin lukuisten goforelaisten kanssa. Kyselin käytänteistä ja jaoimme ideoita, puolin ja toisin. Vinkkejä ja uusia ajatuksia kirjasin itselleni muistiin joka päivä.

Minuun teki erityisen suuren vaikutuksen välitön ja ystävällinen ilmapiiri sekä avoimuus. Tässä työyhteisössä näkyi tasa-arvoisuus, kannustaminen ja yhteisen päämäärän tavoittelu. Ne ovat tärkeitä seikkoja kaikille! Todellinen työn ”imu” ja uuden oppimisen into mahdollistavat vaikka mitä!

Tutustumisjaksoni poikii varmasti jatkossa yhteistyötä Goforen ja kouluni välillä. Opiskelijat tulevat yritysvierailuille oppimaan tiimityöskentelyä ja työelämätaitoja. Opettajat tarvitsevat apua tiimijaksojen suunnittelussa ja toteuttamisessa. Opinto-ohjauksen teematapahtumiin kutsumme goforelaisia asiantuntijoita kertomaan digitalisoituvan työelämän käytänteistä ja urapoluista. Kenties tästä kehittyy vielä jokin laajempikin yhteistyöprojekti! Meillähän on yhteinen tulevaisuuden tavoite: saada alalle eteviä opiskelijoita ja tekijöitä, myös tyttöjä.

 Nyt palaan takaisin opetustyöhön.  Inspiroituneena.

Kiitos Gofore! What a great place to work!

Janna Leskinen

matemaattisten aineiden lehtori 

Tampereen yhteiskoulun lukio

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Pidättelen itseäni aamulla, en malta odottaa ensimmäisen työpäivän alkamista. Miltä työskentely tuntuu Suomen parhaassa työpaikassa?
Odotukseni palkitaan hymyilevillä kasvoilla ja useilla kädenpuristuksilla. Rento, lämmin vastaanotto vie jännityksen hartioistani. Olen seitsemäs työntekijä Jyväskylän toimistolla. Tuntuu hyvältä.

Työvälineet kuntoon ja tutuksi toimistoon


Aamu alkaa mukavasti. Ensimmäiseksi saan Gofore Crew -repun. Repun täyttäminen alkaa rauhallisesti, sillä Jaakko tuntuu varanneen kaiken aikansa kanssani touhuamiseen. Reppu saa täytteeksi pipon, pari upeaa T-paitaa ja Crew-hupparin. Löydän myöhemmin muita reppuun jemmattuja lahjoja, kuten heijastimen, kynän, tarroja, haalarimerkin jne. Jutusteltuamme tovin Jaakon, Jyväskylän toimipiste-esimiehen kanssa, hän esittelee toimitilat. Pidän toimistostamme.
Jaakko kertoo, että kaikki keittiöstä löytyvä on vapaasti saatavilla. Pöydällä on hedelmiä, leipää ja laatikoissa keksejä sekä xylitol-purkkaa. Jääkaapista löytyy kylmäherkkuja leivän päälle ja maitoa kahviin ja murohommiin. Oluitakin näkyy. En uskalla koskea niihin ensimmäisenä työpäivänä. Myöhemmin huomaan, että semmoisen voi napata työpäivän päätteeksi, jos vain kehtaa.
Palkintokaappia ei sen sijaan saa tyhjentää. Palkintokaapista voi ottaa jotain pientä, kun saa kehuja työkaverilta, siis suklaata, leffalippuja tai viiniä. Mainio ajatus! Näin luodaan positiivisuuden kehä.
Fiilis on korkealla lähestyessämme työpistettäni. Pöydältä löytyy pino laatikoita, kaikki työsopimuksen allekirjoituspäivänä valitsemani työvälineet! Goforelaiset saavat tietenkin valita työvälineensä. Kehtaan heti kysyä, että voiko työpisteen valita vapaasti? Samoin tein siirrän koneeni ikkunapaikalle ja nautin maisemista paketteja avatessani. Hymyilyttää.

Lounaalta kulttuurin kimppuun

Aamupäivällä saan yhteyden Gofore-kaveriini. Sellainen löytyy jokaiselle uudelle Goforelaiselle, häneltä voi kysyä mitä tahansa. Ville on lähettänyt sähköpostilaatikkooni etukäteen hyviä vihjeitä ja laittaa slackissä vielä listan keskeisistä linkeistä aloittelijalle. Tuntuu mahtavalta.
Lounashetki koittaa. Menemme Jyväskylän porukalla syömään, Gofore tarjoaa lounaan. Pieni mukava teko saa suupieleni kääntymään ylöspäin.
Lounaan ja parin seuraavan päivän aikana tutustun työkavereihini. Saan tietää, pääseväni tekemään julkkariprojektia ja luen valtavan määrän Goforen kulttuuriin liittyviä conflusivuja. Tietoiskut, Gerhot, käytännöt ja slack. Ruudulla näkyvän tekstin lisäksi saan käteeni painetun kulttuuriaapisen, annoksen tiivistettyä Gofore Crew -fiilistä.

Projektin kick-off

Pääsen heti hyvään vauhtiin, saan tietopaketin uudesta projektistani. Vajaan viikon päästä pidetään Tampereella projektin kick-off. Tapaan siellä projektitiimini. Esimakuna saan Artolta tietopaketin. Se sisältää hyvän yhteenvedon sekä ympäristön pystyttämiseen että sisältöön. Onneksi Ville tekee samalle asiakkaalle projektia, hän auttaa parina ensimmäisenä päivänä ympäristön pystyttämisessä.
Tuntuu todella hyvältä, kun joku auttaa eri komponenttien asentamisessa. Ei tarvitse yksin olla sormi suussa. Homma sujuu yllättävän letkeästi. Pieni vastoinkäyminenkin pitää voittaa ennen kuin päristin lähtee käyntiin ja työskentely-ympäristö on valmis.
Pari päivää ennen kickoffia selvitän miten kuljetaan eri toimistojen välillä. Tietenkin junalla, niin on mahdollisuus tehdä töitä matkan aikana. Confluencesta löytyy näppärästi sarjalippuja, joiden avulla pääsee matkustamaan firman piikkiin. Helppoa ja mukavaa. Näin homman pitäisi toimia aina.

Turistina Tampereella eli tutuksi toiseen toimistoon

Tampereen toimistolle saapuessani Arto esittelee tilat ja tutustun porukkaan. Pukeutumisessa näkyy vahvasti #1 ja Gofore Crew-hupparit. Huoneesta toiseen kulkiessa tulee aivan fantastinen fiilis. Näissä tiloissa ja näiden ihmisten kanssa on hyvä olla. Kaikilta riittää aikaa vaihtaa pari sanaa uuden työntekijän kanssa.
Reilun sadan hengen toimistossa eri kahvipisteille näkyy hedelmäkasoja. Isommalle toimistolle näyttää mahtuvan kaikenlaisia virkistysvälineitä. Jyväskylästä löytyy pöytäfutis, mutta sen lisäksi Tampereelta löytyy biljardi, konsolinurkkaus ja muutama muu rentoutumispiste. Sama mukava tunnelma välittyy molemmilla toimistoilla.

Sprinttejä ja scrumia

Ensimmäinen palaveri jännittää hieman. Uusi ympäristö, projekti ja työkaverit, siinä riittää tekemistä. Koko porukka paljastuu mukavaksi jengiksi, näiden kanssa tulee hyvin toimeen. Ensimmäiset palaverit kulkevat mukavasti. Voin nyökytellä ja tarjota pari kommenttia, mutta lounaan jälkeen keskittyminen herpaantuu hieman. Onneksi scrum-malli tuli tutuksi edellisessä työpaikassa, joten kokous etenee kokemuksen voimalla. Scrum-mallin sisältö puidaan pitkään firmassa olleiden puheella. Kerrankin sprintit ja scrum kulkee oikein, ei tarvitse vääntää kaikille rautalangasta prosessimallia.
Päivän päätteeksi sukellamme koodipuolelle. Porukan asiaosaamisen taso ja tekninen osaaminen tekevät minuun vaikutuksen. Itse asiassa kaikki tapaamani Goforelaiset vaikuttavat ihan tavallisilta ihmisiltä, mutta jollain tavalla älykkäiltä. Keskusteluissa kaikille riittää tilaa ja puheenvuorot sisältävät informaatiota. Kukaan ei heiluttele huulia vain lihaskunnon parantamiseksi. Asiaa kuitenkin riittää.

Intohimolla alkuun ja kiimalla perille

Viikon aikana virinneissä keskusteluissa ja lounastauoilla juttua riittää. Ihmiset keskittyvät kiinnostaviin aiheisiin, he tekevät mielenkiintoisia asioita ja puhuvat niistä. Kyseessä on jotain suurempaa kuin kiinnostus, Goforella puhutaan kiimasta. Intohimolla pääsee alkuun ja kiimalla perille.
Tuntuu hyvältä kuulua Goforen porukkaan. Gofore Crew here I come!

 
 

Avatar

Piditkö lukemastasi? Jaa se myös muille.

Goddamn salespeople

Each and every one of us has probably dealt with some type of ”salespeople”, be it phone salesmen, insurance, car sales, B2B sales etc. And you’ve also probably formed some sort of stereotype of what a salesperson is like, based either on your own experiences or maybe urban legends. A common (mis)conception, especially in the software business is the classical ”over-promise under-deliver” concept. Sales is seen as a problem, always promising customers things that can’t possibly be delivered in the promised time frame. Communication, education or motivation can be some of the reasons behind the issues, but overall it creates an unfortunate circle of negativity. I’m fairly glad that I can honestly say, that this is not the case at Gofore.

Transparency is key

Generally judging something or someone without researching and understanding necessary background information and facts is just plain stupid. Quite a lot of information is open at Gofore, either by just browsing to the appropriate site in Confluence, or dropping a question in Slack to an appropriate channel quickly gets you the information you need. So during one of the (occasionally rather heated, I must admit) sales-resourcing discussions in Slack, I said that it would be interesting to see what a day in a sales role looks like, to understand better how it works. 10 minutes in, and we’d agreed on date with one of our Lead Consultants, Ville. Agile, yeah!

A day in the life of


To understand my point of view a bit, I’m the guy at the customer’s office, wearing a hoodie and noise-cancelling headphones trying to solve various problems with code, happily unaware of the world around me. Guys like Ville handle everything to make this possible.
So heading to meet Ville on a rainy Thursday morning, I had no clue of what to expect of the day.

 9:03 am

Meeting Ville at a Café in Pasila. Ville goes through some of the responsibilities in his role, keeping existing clients happy, providing them with the help and resources they need, acquiring new clients, creating offers, development of a certain industry segment… Quite a lot of stuff. I ask questions and try to get a better understanding of each area of responsibility, but the entirety is not easily understood over a single cup of coffee.

9:40 am

We’re joined by Terhi, another one of our Lead Consultants. We start making our way to the first meeting of the day, a steering group meeting with an existing customer. For the duration of the walk, Terhi and Ville discuss about the situation at the customer, and I start getting an idea of what the meeting is about.

10:00 am

Meeting the customer. Everything discussed here is confidential, so can’t share any of it. What I can say though, that I’m very, very happy that we have people dealing with these kinds of meetings. Even the more sensitive stuff is dealt with in a very professional manner from both sides. Heavy, complex stuff, that, I can say, my Python skills wouldn’t be able to solve.

11-12 am

Making our way back to Kamppi, so we’d be closer to the next meeting in the afternoon. Also, lunch.

1:00 pm

Going through a fairly large public tender, and the current status of the planned offer. Gathering the needed amount of references and all the required information about them, filling up the required forms in exactly the correct manner, finding suitable people to fit the requirements, gathering their CV’s etc. Tons and tons of work, and this needs to be done by tomorrow? Why of course. Also, interesting to see, that at this point it’s been decided to not participate in a part of the tender that would include some, how to put it, hairy tech. As we go through the process I’m also seeing tons of potential for automating parts of the process, to save hours of time. Won’t help for this offer though, as the timeline is so tight. Again, I’m fairly glad that we have pedantic people taking care of these, as it would be a complete mess with my patience and organizing skills.

1:40 pm

We start heading to the next meeting. An existing customer has invited us for a visit, as they have a fairly fresh project going that they would need help with.

2:00 pm

Customer is clearly excited about the new project. He enthusiastically explains the current state and the plan of the project, and I’m starting to get excited as well because we’re apparently dealing with a fairly tech-savvy guy here. Ville is making notes with such a speed that it seems like he’s capturing every word of the requirements on the first go. I’m starting to hear terms that I really like: Cloud, Scalable, Docker, AWS, GCE, REST, React. I can actually take part in this conversation, and I give some comments on the architecture and technologies. Yay! I did something!
We end the meeting on agreeing how to move forward, how to deal with the bureaucracy and when should the needed experts start. Sounds like a very interesting project, I very nearly volunteered myself!

3:00 pm

We end the day by having a beer and going through bits of the day. Honestly, I’m pretty beat and my head is spinning with all the new information. Lot’s of stuff outside my comfort-zone, but I did learn quite a lot. Ville’s day is not over yet though, as he still has to finish the offer for tomorrow.

Afterwords

I’m pretty happy on how the day turned out. With an open mind and zero expectations, I had a great time and now understand a bit more on how sales works.
Any time you’re having a hard time grasping someones side of an argument, try hopping in their shoes for a day, and it might help you to understand them a bit better. Especially in case you’re working for the same business, you’re very likely to have similar goals in your work i.e. for the company to succeed and people to enjoy their time there.

Avatar

Lauri Kuittinen

Lauri is a System Specialist at Gofore, working mostly with DevOps- and automation-related tasks. Word on the street is, that he has been involved with actual Software Development as well. In his free time, he can usually be found at a climbing gym or outside trying to get on top of a boulder.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Goforen henkilökunta on valinnut ehdokkaansa yhtiön hallitukseen. Valituksi tuli tekninen projektipäällikkö Anne-Mari Silvast.
Silvast keräsi itselleen kolmanneksen äänistä. Tarkaksi ääniosuudeksi muodostui 31 %, mitä Silvast ei itse osannut odottaa: ”Gofore on yritys, jota edustan ylpeänä. Tuntuu uskomattomalta, että näin mahtavasta ja lahjakkaasta porukasta tulin äänestetyksi hallitukseen.”
Vaalien tulos julkistettiin äänestyspäivän 10.3. päätteeksi. Äänestysaktiivisuus nousi 87 prosenttiin. ”Omalla äänellä tuntuu olevan vaikutusvaltaa”, epäilee vanhempi ohjelmistosuunnittelija Teemu Erkkola korkean äänestysprosentin syyksi. Erkkola kertoo vaalien teemojen koskettavan koko henkilöstöä helposti ymmärrettävällä tavalla ja kokee, että voittavalla ehdokkaalla on näkyvä ja yhtiön kannalta merkittävä asema.

Ehdokasasettelu ja vaalityö avointa koko henkilöstölle

Kaikilla Goforen työntekijöillä oli äänestämisen lisäksi yhtenäinen mahdollisuus nousta ehdolle vaaleihin. Ehdokaslista koostui lopulta kymmenestä hyvin eri kokemuksella varustetusta goforelaisesta. Ehdolle asettui niin yhtiön ensimmäisiä työntekijöitä kuin alle vuoden uran Goforella tehneitä ja tehtävänimikkeet vaihtelivat ohjelmistosuunnittelijasta, projektipäällikköön, palveluarkkitehtiin ja johdon konsulttiin. Goforen toimitusjohtaja Timur Kärki on vaikuttunut ehdokasasetelmasta: ”Haluan kiittää kaikkia ehdolle asettuneita rohkeudesta sekä avoimeen keskusteluun heittäytymisestä. Vaalikampanjoinnin aikana nähty innokkuus yhtiön kehittämiseen oli käsinkosketeltavaa.”
Jokainen ehdokas kirjoitti oman esittelynsä sekä vaalilupauksensa yhtiön intranet-confluenceen. Vaalityö jatkui koko yrityksen yhteisessä chatissa. Slackissa ehdokkaat vastasivat jokaiseen henkilöstön heille osoittamaan kysymykseen sekä toivat esiin omia mielipiteitään, mihin suuntaan Goforen toimintaa tulisi viedä. ”Vaikka keskustelu eksyikin välillä operatiivisen johdon tontille, niin yksi keskustelun tavoitteista saattoi oman ehdokkaan löytämisen ohella olla aiheiden yhteinen käsittely ja esille nostaminen”, summaa ehdolle asettunut Jarno Naukkarinen. Aktiivisen keskustelun lisäksi ehdokkaat kokoontuivat vaaliväittelyyn. Väittely videoitiin työntekijöille, jotka eivät päässeet sitä suorana seuraamaan.

Uniikki hallitustyöskentely todettu toimivaksi

Goforen työntekijät valitsivat keskuudestaan uuden hallituksen jäsenen nyt kolmatta kertaa. Kahdella edellisellä kaudella valituksi on tullut Goforella palveluarkkitehtina työskentelevä Niko Sipilä. Henkilöstölle Sipilän hallituskaudet ovat näkyneet esimerkiksi sisäisinä blogikirjoituksina, joihin on tiivistetty hallituksen kokouksen sisällöt ja joissa on jatkettu aiheiden analyyttista tarkastelua.
Silvast ei tule toimimaan henkilökunnan edustajana Goforen hallitustyössä, vaan henkilökunnan valitsemana täysivaltaisena hallituksen jäsenenä. Goforen poikkeuksellinen ja toimintatapoja uudistava hallitustyöskentely on saanut tunnustusta muun muassa viime vuonna Hallituspartnerit ry:n Kultainen nuija -huomionosoituksella.
Lisätietoja:
Gofore Oy
Toimitusjohtaja
Timur Kärki
040 828 5886,  timur.karki@gofore.com

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.


Is Angular 2’s state management magic eating React alive? Is React better suited to mobile environments than Angular 2? What if I am just a newbie coder and need to choose between the two?
Two full-contact Javascript professionals Henri and Roope are here to share their secrets. So let’s get into the ring and find the next Javascript framework champion! Feel free to read the introductory, more general Part I as an appetizer.

Fast, faster, Angular 2

Q5: Are there any big performance differences between Angular 2 and React?
Henri: Performance-wise there’s not much of a difference between React and A2. Performance used to be a bit of an issue for A1, but A2 is pretty much on a par with React when it comes to perf.
Roope: Even the initial release of Angular was already faster than React in many cases thanks to its highly sophisticated change detection mechanisms. Angular is also a very young technology, and is continually evolving performance-wise. Angular’s subsequent releases have already brought extra improvements to performance. Also, at the same time it offers excellent performance, it makes it extremely easy to manipulate the state by using a library called zone.js.

Q6: Is the bundle size going to be an issue for React/Angular 2?

Henri: For a React-based app, it depends entirely on your build configuration and the number of dependencies you’re bundling along with React. React itself is just a view library and doesn’t hook into your build-time bundle generation process in any way.
That being said, react and react-dom together weigh in at around 40 kB (minified and gzipped), which is definitely not too much for the majority of use cases.
Roope: Angular comes with ready-made bundling with Angular CLI. Thus you don’t need to spend your valuable time adjusting the builds and reinventing the wheel again and again. Instead Angular CLI provides you an easy to get started sample project along with code generation features besides the obvious highly optimized building and bundling for production. Angular’s architecture with TypeScript and Ahead-of-Time compilation allow it to skip every single not used thing from the bundle.
Since React itself is also relatively small, I don’t see that bundle size would be concern for either. The bundle sizes of course depend on what all you include and thus the comparison in actual size does not make that much sense.

Thick and thin React

Q7: Which technology has a simpler state management implementation?
Henri: As React is just a view library, it only concerns itself with component-level state. Application-level state can be managed in a number of ways at other layers of your application architecture. At the time of writing, the most popular state management solutions to be used in tandem with React are Redux and MobX.
Generally, the complexity of your state management layer should be no greater than warranted by your application’s requirements. For simple apps React’s component-level state might be enough, which is hard to beat as far as simplicity goes. In the majority of cases, however, you are probably going to need a separate state management library. Of the popular two options in the React ecosystem, MobX is simpler, easier to get started with and less opinionated than Redux. On the other hand, Redux gives you a proven state management architecture that might scale better as the size of your team grows.
In the end, the simplicity of your application’s state management layer comes down to the requirements. The view layer, whether it be React, Angular 2 or something else, should not impose any significant architectural constraints when it comes to application state management.
Roope: Angular provides no limitations on the state management. That said, it provides you with an easy solution for some common, basic needs with services. Besides the services, you can easily add the very same Redux from the React world, or use the more user-friendly @ngrx/store which combines the reactive programming library RxJS along with Redux concepts. This allows you to write more elegant code with the knowledge you might already have from earlier Redux usage.
Q8: Let’s say that you are a newbie programmer. Which technology has an easier learning curve?
Henri: Compared to Angular 2, React has a way smaller API surface and less custom syntax to learn. This, coupled with the fact that A2 developers usually have to invest some extra time to learn TypeScript when they get started with their first Angular project, gives Angular a steeper learning curve as compared to React.
It should be kept in mind, though, that Angular gives developers a lot more out of the box than React does, which makes this comparison a little unfair. When it comes to building a full, nontrivial application with either technology, Angular might be easier to pick up for a total newbie as compared to setting up a similar React-based stack and deciding between the various alternatives for routing, state management and backend integration.
Roope: Angular is often mistakenly taken as hard to learn. After giving dozen of trainings on Angular & TypeScript I can assure you that it is not the case. Angular is divided into modules elegantly and the core itself does not have a lot to learn. The components are easy to understand and templates only have 5 well-declared additions to plain HTML.
As compared to React, where you usually first need to adapt the JSX language the templates are just simpler to understand and require no special knowledge about Angular to be understood by anyone with prior knowledge of building modern web applications. Also the same syntax can be more or less found from Vue.js, though the syntax there is a little more hazard.
Also, since TypeScript is very friendly in that it does not enforce you to type everything from the beginning, you can get up and running with Angular straight away without getting to know TypeScript. You just get all the benefits, including code completion for all library code and static error messages for all of your templates and other code.
The last point, but certainly not the least, on this topic is that starting to build an actual React application (not some pet project) requires you to choose dozens of libraries to support you. You need to, for example, choose libraries for the following concerns: routing, state management, testing, test runner, bundling & minification, http requests, form handling, server-side rendering, typing. Angular has a great solution for all of these already available, but as you can read in my earlier blog post, titled Angular is not a massive monolith – but your mom is, this does not mean you couldn’t use any solution you see suitable, but instead you can modify the Angular anyway you see suited.

we are hiring

Is Angular mobile?

Q9: The whole world is going mobile. How will React/Angular 2 respond to market demand?
Henri: The traditional React way to go mobile is building a platform-specific UI layer for Android/iOS with React Native while reusing the code at upper architectural layers across the target platforms. This, in my opinion, is a very sensible way to go about code reuse across different platforms as it allows you to craft a quality UI for each platform using the platform’s native UI components while still being able to reuse the parts of your code that back the UI.
Another, more bleeding-edge approach to going mobile is building a progressive web app, something that Google has been actively promoting for the past year or so. While some browser vendors have been holding back in implementing PWA essentials like the Service Worker, it still looks that, in the medium term, PWAs will become an attractive alternative to traditional mobile apps. Obviously, you could build a PWA using any view library, such as React, as the Service Worker sits way above the UI layer.
Roope: On mobile world, there are three suitable options available. The first and most important one is the Apache Cordova approach where your web application is packaged as a mobile application running on top of the native WebView available on a device. Apps will also have access to all native APIs such as Bluetooth and camera via plugins available. This allows you to write your code with familiar technologies and develop in faster iterations on the browser as well. With the performance of mobile devices these days, Cordova is really the best solution assuming that you aren’t making a game with extremely high-performance requirements. To support this with Angular there is a framework called Ionic 2 which provides a set of ready-made Angular components that work on supported platforms (iOS, Android and Windows Phone) as they would be totally native.
If you are fanboy of React Native, you might be happy to hear that as a second option Angular also supports usage of React Native with Angular React Native Renderer. This way you can utilize the ready-made UI components of native mobile platforms. Development with these is a little bit of a hassle, but can be managed and you can rely on all of your UI elements to behave exactly as native components (since they are). There is also another framework called NativeScript which plays even better together with Angular. These frameworks are also a viable option for mobile app development, especially if you don’t have tight schedules or budgets.
The third option is progressive web applications. These are built on top of web app manifests and service workers, which both still lack the support of some major browsers (Apple’s Safari & mobile devices and Edge). They provide an interesting middle-ground between native applications and websites by providing features such as offline usage, native API access and desktop installable icons. Luckily Angular provides out-of-the-box support for these too via a project called Angular Mobile Toolkit.
As Google has emphasized many times during the release of Angular, it is more of a platform than just a framework. These are all examples of this approach. Angular provides seamless support for all of your needs whether they are for mobile, web or desktop applications. This is one the greatest points of Angular ecosystem.
Q10: The ecosystem around either technology is an important consideration. Which one has the upper hand here?
Henri: Both Angular and React have strong and healthy ecosystems and I don’t see them dying down anytime soon. React, having been around longer than A2, has a head start here, meaning that there are probably more alternatives for React-based apps than there are for A2 apps. Angular users, on the other hand, can also use some of the existing libraries available for A1, provided they have been updated to support Angular 2 as well.
Roope: It is true that React ecosystem has been around a lot longer and has more possibilities available. Still the amount of libraries for Angular is just huge and I’ve never had a situation where I would need a library for certain thing and it would not be available. One important thing here is also that since Angular does not restrict you that much, you can re-use many of the libraries originally made for React world.

Choose a life. Choose a job. Choose React. Choose Angular 2. Choose a life.

Q11: What if I need to get shit done in very little time — like one month? Should I choose Angular 2 or React?
Henri: That would depend on the composition of your development team. If you have a bunch of seasoned Angular veterans with very little exposure to React it would be a no-brainer to go with Angular. Then again, if your team has very little experience building web apps with either technology (or has lots of experience in both A2 and React) the decision comes down to whether you need to use any 3rd-party libraries, and if so, which one has better alternatives to meet your requirements. Other things being equal, it’s a matter of personal preference.
Roope: It of course depends on your specific needs. For quick and simple projects I could go with Vue since it already has all the core pieces available and otherwise is as lightweight as React. Vue also has the Vue CLI to generate everything necessary for you.
If you instead are going to build a more sophisticated application, I would definitely choose Angular. The main reasons for this are the ease of getting started with enterprise grade application architecture that includes, for example, routing and form handling, extensive library support and seamless entree for new developers to the application since the core concepts are always the same. Also, performance will still be top notch and Google’s backing of Angular is an important consideration.
Q12: What if I have an application that will require dozens of developers and years of active development? Should I go with Angular 2 or React?
Henri: What matters more here is consistency in architecture, design and coding practices and how well you’re able to enforce them through your project’s toolchain — it’s not so much a question of which ecosystem to bet on since both are well-established and will probably be around for quite some time.
The one advantage, however, that Angular-based projects might have here is that they’re usually written in TypeScript, which really comes into its own in collaboration-intensive projects when compared to plain JS. Then again, you could just as well add TypeScript or Flow to a React-based project, so in the end it essentially comes down to having a well-thought-out toolchain in place to support your development workflow.
Roope: This one is a no-brainer. Angular is the obvious choice. Why? For really many reasons. This is where Angular really shines. Besides it being easy to get up and running with Angular, it also has a solid architecture for larger applications built-in. This, along with the extensive style guide enforced by the Codelyzer TSLint plugin, provides a solid structure to build on top of. It also makes it sure that any developer who knows the basics of Angular can just jump into the project and be productive immediately.
One important consideration here is also the usage of TypeScript. As you probably know TypeScript provides a flexible static typing system on top of JavaScript. It allows IDEs to provide better auto-completion, analysis and other useful stuff along with support for more sophisticated refactorings to be performed. Even though debatable, I’m a big believer in the benefits of static typing for program correctness and have been able to see the gains in action on a project where we have been building large-scale Angular application for over a year with a dozen developers.
One last thing is the fact that Google backs it up and also depends heavily on it in its own huge applications. Thus the support will be around for quite some time. Also, the roadmap for future releases is quite ambitious. This, compared with Facebook’s backing of React, feels a lot safer. Facebook can’t grow forever and as we all know, the market for social media is constantly changing. If something would happen, supporting the React ecosystem most probably wouldn’t be the top priority for Facebook.

Last words

Clearly, Angular 2 and React are the two sides of the Moon. This blog post shows only a fraction of these two awesome frameworks. And as always, the ruthless but fair developer community will have the final call.
For a wannabe coder like me, this journey has been remarkable. But real heroes are Roope and Henri. It’s amazing to see your passion and knowledge of real software development craftsmanship. You are today’s wrestling stars!
 
Author: Juhana Huotarinen
Experts: Henri Heiskanen & Roope Hakulinen
Graphic design by Ville Takala

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

The Sweet Spot of DevOps

We’ve been blogging about DevOps earlier. We’ve done tons of DevOps projects. Still, it seems that the big DO-wave has just started to rise. This blog reflects from the ideas of the doctoral thesis by Marko Leppänen: Vanishing Point: Where Infrastructures, Architectures, and Processes of Software Engineering Meet and its references. If you feel that you need more than what this blog has to offer, then it is time to get serious and learn from the awesome thesis of Dr Leppänen.

Picture 1: Artistic impression of the DevOps wave gaining momentum

Fast, cheap and realiable!

We all know the holy triangle of software project management. A certain scope of features delivered in a certain time produces a certain cost. Fast release means less features. While business needs to follow a fast changing business environment, long delivery times are unacceptable.

Need for speed has produced Agile methods

In Agile, small feature increments deliver constant value stream in a form of new software features. Small increments ensure a continuous value stream, enable a rapid feedback and create a tighter co-operation with the customer. A dream come true.

Picture 2: The holy trinity of project management. You may visually think that the triangle must stay equilateral or you loose quality. ”Cost” may be also tought more generally as resources. And ”Requirements” as value produced.

Continuous Deployment

Continuous Deployment minimizes the overhead related to software integration, testing and installation. While it becomes possible to add and remove features easily from the live product, it enables the real end-users to experimentally define the real value of the features. Fast release cycle requires adequate maturity level of DevOps. The maturity level is defined by the overall execution of Process, Infrastructure and Architecture.
OK, sounds like a plan. I wanna be continuously agile. How hard can it be?

Speed is pronounced P-A-I

For the rapid increments to work, all the additional overhead needs to be minimized. In other words, everything must be automated. That means tons of tools. The software architecture itself must support incremental releasing. So, you need a modular architecture. In other words, Continous Deployment requires a combination of process, architecture and infrastructure decisions.
Picture 3: Can you find the sweet spot of DevOps from the picture with three bubbles?

Process

Process can mean anything. Here it means people and ways-of-working. You need the people with the right skills and the right mindset. And you need to empower them. When you have the right people, the process acts as a catalyst or blocker. In other words, you need ability from people and Kaizen from processes.
I’ve divided the Process into sub-chapters titled Culture, Testing, Decisions, Crossfit and Measure. Before going into those, let me draw you a pie diagram about it. OK, let’s make it two.

Picture 4: People pie lists the ingredients of personal ability. Process pie describes the Kaizen style continuous improvement. You need both, but start with people. If you’re gonna have only one pie, please make at least sure to make a double crust apple pie.

Culture

Organization ensures that someone has knowledge and authority to take care of all the functional areas of the software development. Stuff like requirements and bug tracking, development, testing, deployment and quality assurance.
There will be cross-functional roles and independent roles. For example, architect versus quality manager, as well as developer versus tester should be independent to avoid bias. Similarly, operations requires different mindset compared to development. You don’t need much of old school organization structures, but clear roles and mandate to act.
A situation where people do not have opportunity to coordinate, collaborate, or cooperate their work is called social debt. It is a parallel for technical debt at the organizational level

Testing

In agile world tests are often developed even before the actual functionality. Integration and testing is being executed automatically, triggered by push to version control. This requires some infrastructure and tooling. But first of all it requires the right mindset. You need to include testing into development.
High speed of development is not enough alone, as the development also has to have a direction and quality

Decisions

Decentralized decision making enables timely and effective decisions. This is a form of minimum viable management, where the decisions are made based on collective intelligence. In the knowledge work there is often a need for timely decisions on complex subjects. In such environment, the only timely and precise decision method is based on collective intelligence.
In the complex domain there are no right answers. Therefore, one needs a safe-fail environment

Crossfit

Cross-functional people enables flexible resourcing and fast decision making. Individuals are able to support each other on their assignments. ”Anyone” can take over anyone else. This kills hierarchies and siloes, enabling wider scope of information, decentralized decision making and transparent ways-of-working. Cross-functional consists of both skills and attitude. Attitude first, skills will follow.
”Social developer” is an overarching concept, where tools, methods, and processes must be in line with each other

Measure

Metrics are collected automatically by the infrastructure. Metrics are used as a base for decision making. Metrics force continuous improvement. Metrics enable fast and timely decisions. In DevOps world the production environment metrics describe the value of existing and newly deployed features.
Increased situational awareness caused by the quick feedback improves developer motivation

Infrastructure

The nature of the tools used for development, testing and deployment depends widely on the domain, technology stack, legacy and user preferences. Still, a continuous deployment pipeline from coding to deployment is required. Process and infra are interrelated, while infra is used as means to automate and speed up the processes. As you know, culture beats strategy. So, for example a cloud strategy is useless if the people disagree.

Infrastructure and process are interrelated

Architecture

Architecture depends on the chosen tools and technologies. I’ve divided Architecture into sub-chapters Modular and Deployment. There is a reason I’ve taken the Deployment (infrastructure) chapter under Architecture. Keep calm and read on.

Modular

Code produces the functionality of the system. Architecture acts as an enabler for the non-functional requirements. Combination of these two can be thought to represent software quality. ISO classification for software quality follows functionality, reliability, usability, efficiency, maintainability and portability. Inside-outside division of the quality means that quick-and-dirty implementation of an external feature creates technical debt inside the code. Technical debt slows the future development. On the other hand, debt can be seen as a resource, which helps to cash in valuable features faster. However, payback is inevitable. Most common form of payback refactoring. Automated tests are the only way to ensure that the payback flows the right direction.

Technical debt leads to inaccurate time estimates and speed makes the technical debt visible

Deployment

Technology selection is an architectural decision. There is a clear connection between the selected architecture and ability for fast deployment. The power of agile comes from small incremental and iterative updates. A live installation is a sign of the done requirement. In Lean terminology all the non-live code can be seen as inventory and waste. After the continuous integration works, the next logical step is continuous deployment. Operations isn’t a separate of Development but a logical continuum. Here comes the big ideological step to treat the environment as a part of code. In DevOps development quality assurance and operations form a holistic approach.
Here’s a cool old-school picture presenting the logic of DevOps. Yes, it’s old school while only the PO is having a beard.
Picture 5: DevOps big picture.

Continuous * (everything)

Continuous * provides numerous benefits. Fast delivery feels good at the both ends. Quick feedback increases situational awareness. Flow and visibility increases the developer and stakeholder motivation. Continuous * focuses the communication on what matters most. End users are measured on real-time, so there’s no need for error reporting. Developers can just commit, no need to inform anyone. Automation takes care of the process. Business owners dare to try new ideas, while proof-of-concept implementations are fast to deploy and self-evident to measure. Failing is fast and safe. Everybody are Lean and beautiful.

Five cents

Remember PAI. Process, architecture and infrastructure are interrelated.
1. Have a well-automated deployment pipeline that is fast to setup
2. Have identical production and development environments (that are fast to setup)
3. Use fast communication and feedback channels
4. Be Lean
5. Don’t use the domain as an excuse. Speed is a state of mind

Jari Hietaniemi

Jari Hietaniemi

Jari on yksi Goforen monilahjakkaista palveluarkkitehdeista. Hänen ydinosaamistaan on monimutkaisten sekä laajojen tietojärjestelmähankkeiden suunnittelu ja vetäminen. Jarin filosofian mukaan projektipäällikkö on tarvittaessa myös myyntiedustaja, innovaattori, laatupäällikkö, tekninen suunnittelija ja henkilöstöesimies samassa paketissa. Hänen monipuolinen kokemuksensa ja valmentava tyylinsä vievät projektit laadukkaasti maaliin sekä tuovat myös uudenlaista ajattelua ja draivia kohdeorganisaatioon.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Kaksitoista tykyä vuodessa?

Goforella työhyvinvointi on poikkeuksellisen hyvällä tasolla, mistä kertoo sijoittuminen Suomen parhaaksi työpaikaksi Great Place to Work® -tutkimuksessa. Työpaikalle on aina mukava tulla ja jokaisella on tärkeä paikka Gofore-yhteisössä. Työviihtyvyyttä kasvattaa upeat toimistotilat, yhteiset tapahtumat ja vilkas Gerho-toiminta. Yhteisvastuullisuuden lisäksi virkistäytymisestä huolehtivat jokaiselle paikkakunnalle valitut viihtyvyysryhmät, jotka ovat vastuussa muun muassa toimistoeduista ja tyky-päivien järjestämisestä. Tampereella isompia tyky-päiviä on järjestetty edelleen kaksi kertaa vuodessa. Niiden merkitys on kuitenkin pienentynyt, kun Gerho-illat ja vapaa-ajan tapahtumat tarjoavat jatkuvaa virkistäytymistä työarjen lomassa.
Tampereen viihtyvyysryhmän tavoite on hitsata goforelaisia entistä tiiviimmäksi yhteisöksi. Ryhmän mielestä jatkuvan kasvun myötä yhteisöllisyyteen panostamisen merkitys kasvaa. Viihtyvyysryhmä haluaa, että työyhteisössä säilyy ilmapiiri, joka on valmis ottamaan vastaan lämpimästi jokaisen persoonan.
Viihtyvyysryhmä päätti kyseenalaistaa nykyisen tyky-konseptin ja uudistaa virkistäytymisen toimintapoja. Aikaisemman kahden tykyn sijasta Tampereella siirrytään kuukausittaisen mallin kokeiluun. Jatkossa tykyt siirtyvät enemmän Gerho-vetoisiin iltoihin, mikä tuo ohjelmaan vaihtelevuutta, sisältö pysyy kevyenä ja ideointi perustuu enemmän itseohjautuvuuteen. Viihtyvyysryhmä voi antaa kipinän, mutta viihtyvyystoiminnan polte pitää roihahtaa yhteisössä.
Tarvitaanko virkistäytymiseen ulkopuolisia tapahtumajärjestäjiä, vahvoja virvokkeita tai näyttäviä sirkushuveja? Entäs jos tyky olisi piknik Sorsapuistossa, reipas lenkki pakkasessa ja avantouintia, standup-viihdettä toimistolla tai siipiä ja MM-kiekkoa? Ketään ei pakoteta osallistumaan, vaan jokainen voi itse valita osallistuuko mihinkään vai kaikkeen. Jokaista on aina vaikea miellyttää, mutta todennäköisemmin kahdestatoista tykystä löytyy viihdykettä useammalle kuin yksittäisestä kaikille.

Tampereen viihtyvyysryhmä

Avatar

Elina Hulkkonen

Piditkö lukemastasi? Jaa se myös muille.