Railsin rakenne

Reading Time: 2 minutes

Rails on mukava, koska

  • saat paljon Railsista valmista rakennetta sovellukselle
  • tyyli ja laatu on kohdillaan Railsin valmiissa palasissa
  • Ruby-yhteisö on tunnettu avuliaisuudestaan – ja erittäin selkeästä englannista
  • Rails (ja Ruby-kieli) on taistelutestattu ja ollut olemassa oikeasti pitkään
  • Rails uudistuu jatkuvasti, mutta tahti ei ole niin älytön että stressaisi

No niin… Ruby alta pois ensin!

Viihdyn uutta oppiessa. Toki kokemuksia on erilaisia. Aiemmat pidemmät / laajemmat suhteet ovat olleet:

  • BASIC
  • C
  • Java
  • PHP
  • JavaScript
  • TypeScript
  • React Native

ja toki liuta muuta, kotitarpeisiin.

Raiteille! Rails soikoon

Rails on Rubyn päälle rakennettu “systeemi”. Ruby on siis varsinainen ohjelmointikieli siellä taustalla. Rubyyn kielenä voi tutustua vaikka erinomaisen Wikipedian kautta. Ja oppimiseen löytyy reippaasti resursseja. Ruby on kielenä mielestäni “varsin jees”.

Viimeisen ~8 vuoden ajan en ole koskenut Windowsiin, ja sitä kautta mm. sh- skriptat tulleet paljon tutummiksi. Rubyssa kielenä on jotain erityisen kivaa, syntaksi on aika selkeä, ja silti sallii pieniä hemmotteluja; shorthandeja. Jos on tottunut tosi säännölliseen kieleen, esimerkisk

Erikoisuutena on aika siisti ja sallivakin syntaksi. Kun olen kirjoitellut kohtuu paljon erilaisia bash-skriptejä ja sitä ennen myös muilla järjestelmäliimoilla tilkinnyt systeemejä, tuntui kotoisalta huomata että Rubylla voi kirjoittaa varsin samaan tyyliin hyvin kompakteja, lyhyitä ohjelmia. Ruby kuitenkin on varsin puhdas designin puolesta, joten se ei ole omiaan suosimaan spagettityyliä.

Oma käsitykseni Rubysta kehkeytyi siten, että aluksi kieli tuntui kovin suppealta ja jollain tavalla “ei riittävän ilmaisuvoimaiselta”. Sitten myöhemmin huomasin, että kieli on omalla tavallaan varsin elegantti. Se ei ole kuitenkaan niin puristinen kuin voisi ääritapauksessa kuvitella. Rubyssa on pyritty tuomaan luonnollisuutta (pragmaattisuutta) ja esimerkiksi kieleen on rakennettu villejä veikkauksia yleisimmistä tavoista, joilla kieltä tuntematon ohjelmoija voisi haparoida metodeja. Eli, vaikka aina ei muistaisi, oliko se jonkun asian pituutta (ts. alkioiden määrää mittaava) metodi .size vai .length – molemmat käyvät!

Ruby on tulkattava kieli, käytännössä “väistämättä”, sen ominaisuuksien tarvelistasta johtuen.

Entä se Rails?

Söpö. Timmi. Hyvin dokumentoitu. Neuvotteleva. Aika DRY. Funktionaalinen. Sallii kaiken, tarvittaessa.

Railsin kautta saa varaslähdön erittäin runsaasti varusteltuun laadukkaaseen ekosysteemiin. Kun katselee esimerkiksi tutorial-tason tai pidemmälle vieviä videoita (vink: Railscast Youtubessa), huomaa jälleen, että laatu on kauttaaltaan hyvä: asiat on usein mietitty, opetuksen pedagogiikka on keskivertoa parempaa.

Teemat toki toistuvat Ruby on Railsissa aika lailla kuten monissa muissa.

Ja se rautatielogo!! Kaikki tykkäävät salaa sydämmessään rautatiekulttuurista.

Rails itse on kirjoitettu kokonaan Rubylla. Koko tekniikkapino on täysin avoin, joten yksityiskohtiin voi tutustua mm. Githubin kautta.

Toki se on vain jonkinlainen tunne, mutta ainakin itse luen Github:n projekteista heti ensifiiliksiä. Eräs kohtuu tärkeä asia, varsinkin jos on useita eri vaihtoehtoisia projekteja jotka ajavat saman asian, on käytettyjen teknologioiden kirjo. Tämä analysaattori  tunnetaan yleisesti (?) nimellä Linguist (Github). En pidä kovin paljoa hyvin tilkkutäkkimäisistä teoksista. Jos projektiin on lätkäisty 6 eri ohjelmointikieltä ja vielä lisämausteet päälle, alkaa puistattaa. Kynnys pureutua projektiin nousee välittömästi. Rails-projekteissa monesti tämä kirjo on hyvin matala – usein jopa koko projekti on kirjoitettu vain yhdellä kielellä: Rubylla, eli Railsin alla olevalla kantakielellä.

Mikä Railsista tekee “kivan” ?

Heitän näitä aika naiivista näkökulmasta. Vielä ei ole kilometrejä alla kovin paljoa. Tein periaatteessa ensimmäiset “hieman isomman” Rails-softan 2018. Sitä ennen testailin oikeastaan pelkästään Rubya, sellaisenaan, kielenä – ilman Railsia.

Rails

Rails on minikokoinen öljynporauslautta web-palveluille. Sisältä löytyy kaikki, kuntosalia ja elokuvateatteria myöten, mutta jos haluat plaanata aalloilla nokka pystyssä custom-sikariveneellä 50 solmua tunnissa, Rails ei välttämättä ole oikea valinta. Kuten kaikissa uusissa teknologioissa, kokeneen mentorin antama opastus on kullan arvoista myös Railsin kohdalla. Monista muista jutuista poiketen, Railsistä on myös erittäin hyvälaatuista materiaalia netissä, sekä Youtube-videoina että webissä mm. Ruby on Rails Guides sivustolla.

Ohjelmistot vs. bakteerikasvustot

Reading Time: 2 minutes

Mielenkiintoinen ajatus nousi aamulla; intuitiivisesti, ohjelmistojen kehityksen nopeudesta.

Ohjelmistot ovat koodia, siis tekstirivejä. Tietysti rivit pitää osata kirjoittaa, eli niillä kuvataan oikeastaan tekoja (algoritmit) ja asioiden välisiä suhteita (tietorakenteet). Käytännössä sillä, mikä alusta tai teknologia valitaan (C, Java, JavaScript, Ruby, Python, …), ei muuta tätä yksinkertaista faktaa.

Kun palikoita on riittävästi laitettu pinoon, jonoon ja kyljelleen, syntyy ohjelmisto.

Alunperin ajattelin pelkästään ohjelmiston kehitystä nosteen ja vastuksen avulla, tästä syntyisi aika helposti se kuuluisa S-käyrä, jossa on kaksi “tasoa”: tukitaso ja katto.

Ajattelin tuollaista S-käyrää, biologista. Biologisen populaation kasvussa on neljä vaihetta:

  1. kasvuolosuhteisiin mukautuminen
  2. kasvun alku
  3. nopean kasvun aika
  4. kantokyvyn saavuttaminen, kasvu pysähtyy

S-käyrä on hieman eri kuin (talouden nousuaikoina, “good times”) käytetty hockey stick, jossa usein kuvataan eksponentiaalista jonkin asian alkukasvua. S-käyrässä ei edes kuvitella, että kasvu olisi ikuista – olettaen ceteris paribus.

Biologisesti esimerkiksi bakteeriviljelmät ovat usein aluksi täysin eksponentiaalisella kasvulla eteneviä. Koska viljelmän kasvu perustuu solun jakautumiseen, ja jokainen solu jakautuu keskimäärin tietyn ajan kuluttua, saadaan sama ilmiö kuin ydinräjähdyksessä: ketjureaktio. Sitten, jonkin ajan kuluttua, kuitenkin bakteeriviljelmässä tulee rajoite vastaan: yksinkertaisimmillaan tuo rajoite voi olla tilanpuute, tai esimerkiksi ravinnon puute. Tai tautien lisääntyminen populaatiossa. Rajoitteet pakottavat tasapainotilan, jossa syntymä ja kuolema ovat yhtä suuria. Näin populaatio ei pääse kasvamaan tietyn määrän yläpuolelle.

(Palaan muuten myöhemmin tähän pieneen nyanssiin; “koon” käsite bakteeriviljelmässä vs. ohjelmistossa)

Analogioita?

Ohjelmistoissa aivan kuten bakteeriviljelmässä alkuunpääseminen on tutun kuuluista:

1. The Lag phase
   During lag phase, bacteria adapt themselves to growth 
   conditions. It is the period where the individual bacteria
   are maturing and not yet able to divide. During the lag phase
   of the bacterial growth cycle, synthesis of RNA, enzymes and
   other molecules occurs. During the lag phase cells change
   very little because the cells do not immediately reproduce
   in a new medium.

Hetkonen? Nyt tuntui tutulta! Mikä vaihe on kyseessä ohjelmistoprojektissa, kun bakteeriviljelmässä tapahtuu ylläolevaa?

Viritän muutamia kysymyksiä seuraavaa osaa varten.

  • jos ohjelmistojenkin kehitys alkaa hyytyä, miksi silti projekteja tehdään usein monien vuosien ajan?
  • onko ohjelmistolla samanlainen absoluuttinen raja kuin bakteeriviljelmällä?
  • miten isoja oikeat ohjelmistot ovat?

Ideoita? Paina kommenttia! Kiitos, ja jatkuu osassa 2.

Basis for the prophets of Remote

Reading Time: 2 minutes

The world seems to be talking about digitalization. It’s rather elusive subject at times. I like to think of digitalization in very simplistic way: how much does it save effort?

The core of digital work (in software) is keeping your eyeballs on the screen, your mind concentrated, and the environment in a shape that supports you physically. The rest is minor things. There’s thus quite few real pre-requisites for successful work:

  • fast Internet access
  • 220V outlet for laptop charger (ie. normal electricity)
  • a table for work
  • decent weather (preferably indoors)
  • calm atmosphere (not too much buzz and noise around)

There are of course some aspects of team work involved, but basically for the sake of keeping the story simple, we can think of the software and consultancy work as place-independent.

Enter Sowell

In the spirit of American economist Thomas Sowell, let’s ask “what’s beyond the obvious”. We ask the “what implications does remote working actually have”, beyond this explicit definition we just gave.

  • work quality
  • work amount
  • customer benefit
  • benefit for the corporation (employer)
  • environmental benefits
  • any other pros?
  • what about cons?

One of the biggest promises of digitalization is that it makes location (and time) irrelevant. That’s one really interesting feature I found, working at Mainio Tech, a Helsinki-based software consultancy company. The infrastructure was in its native form designed so that it supported remote work. The tools and setup was there, no need to “start thinking” of how to enable remote work. It made a big impression on me. It was also a strong “Eureka!” moment to observe what it takes for things to click properly.

Sometimes there are technical barriers to remote work. They’re often in reality overcome with technology. The question remaining is the shared vision of what can be achieved with a distributed workforce.

 

 

Refactoring and the Code Gremlin

Reading Time: 3 minutes

Refactoring aims to change software’s static structure – the source code. It’s not often so much about the performance (run-time), but rather how a developer perceives the source code. You might even say, the ‘elegance’ or ‘beauty’ of the code.

Refactoring itself can be a beneficial mental process, during which developer takes a second glance at the form of the solution; it might also reveal bugs.

Let’s take a look at 2 fundamental cases.

“Copy-paste”

Especially with a novel tech stack, copy-paste is good way to accelerate learning. Be it Ruby, CoffeeScript, or some latest twist of JavaScript, having examples is a soothing and very often used way to kick-start our own code. There’s certainly no scarcity to source available nowadays: GitHub, Stack Overflow, blogs, you name it.

I remember in 2015 when learning “real JavaScript” how many things were cute tricks on the language, since JavaScript was (and basically is) a very simplistic but kind of crude language. Only lately it has started to have some syntactic sugar in it, so you don’t have to write so much tricky stuff to get ordinary things done.

A Stretch (and its rebound)

Many times there are phases in a software project, during which a developer ‘stretches’: makes an adamant commitment to work until a feature works; however rudimentary, but still it “works”.

Say, you’re making the network connectivity features, and the first RESTful API call requires some more boilerplate code than you ever thought.

The concept is something that you know is viable, so you start stretching the solution: create all variables you might need; crunch the call string (don’t care yet how it looks), and fire a first call to see what possibly happens. You get an answer, so lo and behold! You know the server has received your packet of data! That’s great!

Encouraged by this you add bit more to the code to really get going. In fact, you need to do some parsing on the return packet. Then you need to wire the error handling code, and… more. You now got some 50 lines of code, which indeed seems to work.

You are pacing forward, doing the simplest and most rudimentary code that will get the job done. The intermediary product, you know for sure, is full of bad practices, but that’s ok – for a while. You know that the code gets a second review and things will be refactored.

Stretch as combat experience

Making brave stretches is indeed quite an important part of programming. During a stretch, it might feel uncertain and being out there in a jungle, without a compass, you as a developer are also putting a lot at stake: there’s a chance that the solutions a) won’t work b) was completely the wrong one to begin with. But nevertheless those stretches are crucial for keeping the velocity (going forward) in a project. You are trading risk for risk: by taking some risk you alleviate the risk of being faced with an unknown task, of whose complexity you cannot say anything certain. Now that you’ve done the rudimentary code, you know a thing is doable, and you know the basic solution structure. Even if you wouldn’t accomplish a working solution, you have gained experience of the problem domain.

What about the promise of cleaning up?

If you ever played with LEGOs, or had a hobby that required building stuff with your hands and tools, you know how lucrative it is to “forget” cleaning up. Putting tools in their own place, cleaning trash, collecting and organizing stuff is rote task compared to the challenge of conceiving something novel. Having spent time in perfect flow, and probably feeling either accomplishment (or apathy for the lack of it), cleaning up and restructuring the code feels like an inferior task.

So, to recap: the tendency to favor even hasty development to stagnation is actually very healthy. The thing that’s often forgone is that if you never clean up the mess, it’s going to be what you’ll stare for a long time – maybe not this month, or even this year, but believe me – there are no code gremlins that tidy up things automatically for you, when you’re asleep.

Responsive? React Native and Tackling platpourri

Reading Time: 2 minutes

IMG_3746.jpgIt was a moment of joy!

Sometimes ideas flow, very suddenly, abruptly, and they seem just such perfect fit. Then comes the amazement; why didn’t I think this before?

I’ve done mobile software development on three rather distinct stages of the ecosystem: very early (2000-2001), Single Page Apps, and now Current Age of Cross-platform Apps (2016- ).

Open source components are all the rage, and there’s plenty of schools of thought to follow. Once you settle, you might settle for React Native.

My tool for the trade is React Native, for now. That’s what I’m giving an example about next.

Initiation rites

Many developers from the World wide web, who come to RN, transition rather quickly from the syntax shock, on to inspect and learn the real joys and capabilities of the new platform.  Tooling issues apart, things start to look very good. The initial pain of creating a component subsides, and you hit that 17 lines-and-no-bugs-look-ma! bar. Keep the compiler in the loop, and things are fine. Emulators hot-reload your creations, and the cycle feels good. React Native itself drips and distills to newer versions, like that Elixir Generator of Clash Royale.

The “dark clouds” equation

Every mobile developer probably at some point of their lives thinks about this kind equation:

B = OS * D * ORIENT

The number of branches to develop (&test) is an equation involving multiplication between three factors:

  • OS: operating systems (iOS, Android, Windows Mobile)
  • D: distinct display sizes
  • ORIENT: screen orientation (landscape/portrait)

Plugging mere (2, 3, 2) gives you 12 branches. Auch!

In web-world, you’d have to plug another major multiplication factor, the number of Web Browsers (Opera, Mozilla, Chrome, IE, Safari, perhaps their mobile equivalents, too!). So, in the mobile development this is rather optimistic figure.

Developing a strategy to tackle platpourri

Insert “platform” and “potpourri”, and you have the platpourri. One has to tackle this somehow, “on an intelligent way and in the proper level”. Chaos containment is evident for a sane developer life.

React Native gives you a freeride!

React Native actually drops the OS completely from the Dark Clouds equation, which is great! That means you’re down to 6 branches. Androids come in a chameleon infinite variety, that might prove to be a bit of headache. Anyway, a strategy will formulate.

Then comes the big question: “But wait! Where’s all those responsive design mechanisms in React Native’s components??”

They seem absent.

Responsive, mobile; device independent pixels.

Responsive, mobile, device independent pixels.

Are you getting it?!

Me neither.

No, wait! Hold on for part 2 – it’s boiling. I might have something up my sleeve.

 

Lure of Coding: Packages galore

Reading Time: 2 minutes

Lure of coding.

Once you snap, you can’t.. live without? Update? Stay abreast?

The dream of doing software by snapping together nice libraries (components) is as old as the trade itself.

We’ll be looking at

  • how does modularity in general change software development process
  • how the NPM package repository and ‘npm’ tool helps JavaScript developers
  • is the “Lego-land” approach to building software now a reality?

This article is a not a quick “5 steps to…” -type of article. Rather it’s about the philosophy of software development; the nature of solutions, and a bit of historical review for those who have not done coding in the 19xx’s.

Preface: Was software always modular?

No. Modules were kind of “invented”. In the truly old times, programs were a sequence of lines, executed by a computer as a linear sequence (batch processing – Wiki). Along the execution of a program, side effects did things like set values to variables. In the end, the variables were printed out on a printer paper or some kind of console. Typical use case: given parameters of a building project, calculate the cost estimates and print out a schedule for the project.

Then came two things:

  • The User
  • a need from the developer’s side to manage large programs

The User immediately brings “interactivity”: you can’t know what parts of your program get executed in which order. User navigates your software, triggers different kind of changes in it, and the user also does things you never knew was possible, or desirable. In the long run it’s quite a challenging job to balance the different user needs with keeping the program technically manageable and its usability high (software being easy to use).

The developer’s needs, on the other hand, have to do with the limits of our brain: seeing thousands of lines of linear but highly “spaghettized” code, characterized by jumps between chunks of the code, buried in IF…THEN cases, becomes a human headache. A computer never has a headache; sure, it can be slower to execute highly branched code, but the computer never “loses it”. We might.

Spaghetti code was difficult to debug, especially once a bug crept into the logic. Bugs are behavior of a software that is clearly against the specification. For example, if you get an “infinite” reading for a velocity of a real-world vehicle, you most liekly have some kind of bug in the software.

Side effects change the state of a program in abrupt manner, and the reality was that especially when handing over work from developer to another, things got really hectic. It probably took at least weeks or months for a newbie to familiarize with the “way of the program does things”. There’s quite scarce set of “by the book” -solutions to problems. Software engineering is inherently humane art, curiously, in that developers tend to easily roll their own solutions, once they get bored with looking for a perfect existing recipe. The more experience, vigilance and skills you have, more likely you are to be able to use well-known libraries and patterns. If you’re just beginning to do code, it’s inevitable that you’ll come up with exotic and rather backwardly solutions at first. And it’s completely ok — a necessary training part of becoming a good developer.

Next up, we’ll talk about batches, visit Object-oriented programming, and ponder on our ability to stand on the shoulders of giants. See you!

Refactoring tools for JS development

Reading Time: < 1 minute

Part 1/3

The technology scene changes yearly. With JavaScript, it changes daily – that’s at least what some have come to believe.

This essay is about making refactoring in the software source code level.

This essay does not go into the theory and practice of refactoring, ie. the details of what the ‘smells’ are in various languages etc.

Instead, this is general piece of writing explaining the practical background of building a refactoring tool, especially for language that might be a bit more difficult target: JavaScript.

Why not just use the tools of the trade?

Why not? Why JavaScript is difficult to refactor? Or is it?

We’ll get to the question much more deeply! See you in the next
part.

Kriittinen Intel AMT haavoittuvuus (etähallinta)

Reading Time: 2 minutes

Haavoittuvuuden tunniste

Sisäisesti Intel kutsuu bugia “INTEL-SA-00075”. Kansainvälisesti se on tunnettu nimellä CVE-2017-5689

Millainen bugi on kyseessä?

Huonosti toteutettu osa Intel AMT -etähallintajärjestelmässä, joka kohdistuu pääkäyttäjän salasanan tarkistukseen, tekee järjestelmän käytännössä täysin turvattomaksi: salasanaksi riittää pelkkä tyhjä (“ei mitään”). Tämä koskee tietokoneita, joissa on jokin alla olevaista Intelin AMT firmwaren versio:

  • 6.x
  • 7.x
  • 8.x
  • 9.x
  • 10.x
  • 11.0
  • 11.5
  • 11.6

Jos hyökkääjä pääsee samaan sisäverkkoon, missä tietokone sijaitsee, hän voi ottaa yhteyttä pieneen AMT:n sisäiseen web-serveriin, ja avata täydet oikeudet antavan etäyhteyden. Tämän myötä hyökkääjä omistaa koneen käytännössä täysin, loogisella tasolla: hyökkääjä voi asentaa ja poistaa ohjelmia, päättää mitä koodia ajetaan ennen koneen käyttöjärjestelmän käynnistymistä; jne. Hyökkääjä voi myös asentaa esimerkiksi uusia etähallintatyökaluja (takaovia, rootkittejä).

Pieni virhe firmware-koodissa: suuri vaikutus

AMT-ongelman ydin on kooditasolla yhdessä merkkijonon sisältöä vertaavassa
komennossa. Merkkijonoa verrataan C-kielen ‘strncmp’ funktiota vastaavalla rakenteella. Koodi ottaa 3 parametria: kaksi merkkijonoa, ja kokonaisluvun. Ohjelmoija on valinnut väärin kolmannen parametrin, jolloin verrattavien merkkien määrä otetaankin yritteen pituudesta, ei oikean asetetun salasanan pituudesta.

Kyseinen kohta koodissa vertaa sisäänkirjautuvan käyttäjän antamaa salasanaehdotetta oikeaan, tunnettuun salasanaan. Kokonaisluvun tehtävänä on rajoittaa vertailun pituutta: toisinsanoen jos esimerkiksi N=2, verrataan vain 2 ensimmäistä merkkiä, riippumatta olisiko oikea salasana pidempi.

Tällä on kahdenlaisia vaikutuksia:

  • vakavampi vaikutus on, että myös tyhjä salasanayrite päästää sisään
  • sivuvaikutuksena saatta olla, että oikean asetetun salasanan vahvuus heikkenee sanakirjahyökkäys-tyyppisissä skenarioissa

Mikäli hyökkääjä on havainnut, että kohdejärjestelmässä on AMT-haavoittuvuus, hän voi suoraan käyttää helpointa mahdollista hyökkäysmenetelmää, eli tyhjää salasanaa.

Mikäli hyökkääjä turvautuu sanakirjahyökkäyksiin, ja hyökkääjä ei tiedä AMT-haavoittuvuuden mahdollistamassa helposta tyhjästä salasanasta, silloin hyökkäykseen käytetty aika voi alentua jos hyökkääjän arvausalgoritmi suosii tai sisältää myös lyhyitä yritteitä. Esimerkiksi oikean salasanan ollessa monimutkainen ‘tj5_a#tksPqasc’, niin yrite ‘t’, ‘tj’, ‘tj5’, kaikki menisivät läpi. Tällöin arvausaika voi olla hyvin pieni, eli monimutkaisenkin salasanan voima heikkenee merkittävästi AMT:n myötä. Rainbow-algoritmeja kannattaisi toisin sanoen muokata siten, että ne käyvät ensin läpi tällaiset helpot hedelmät. Voi olla, että niin ne jo tekevätkin?

Miksi React? Mitä se tarjoaa?

Reading Time: < 1 minute

React, kuten mikä tahansa kirjasto tai kehikko, tarvitsee hissipalopuheen. Joskus valinta saattaa yksinkertaisesti hoitua kauniisti sanoen “automaagisesti”, eli projektissa on jo
valittu teknologia(t), tai et ole se, joka päättää arkkitehtuurista.

Joka tapauksessa JavaScript/web-devaus -maailma on täynnä teknologioita, ähkyyn asti, joten uuden esittelyyn ja suosion saavuttamiseen usein halutaan tiivistetty kuvaus.

Reactin avainpointit

  • paino fronttikehityksessä (“View” MVC:stä)
  • nopea (mm. virtuaali-DOM)
  • React on suosittu, taustalla iso talo
  • avointa lähdekoodia täysin
  • modulaarinen

Haemme hieman työkalujen valinnassa samaa, kuin maanviljelijä leikkuupuimurista: ei haittaa, jos laite on hieman monimutkainen, kunhan se tekee itse työnsä tehokkaasti. Toisaalta, Occamin periaate eli Occamin partaveitsi, jota myös noudatetaan usein teknologian kanssa, kuuluu: ‘kilpailevista, yhtä selitysvoimaisista teorioista tulisi valita yksinkertaisin.’ Jos kaksi teknologiaa ajavat saman asian, ota yksinkertaisempi.

Ennenwanhaan varsinkin näillä asioilla oli paljon merkitystä: oli turha pitää ylimääräisiä kilo- tai megatavuja tuotteessa, koska sen levitys (käytettiinpä levykkeitä tai Internetiä), oli aina kalliimpaa mitä enemmän tuotteella oli kokoa. Nykypäivänä rajoitus on löytänyt muotonsa lähinnä tuotteen turhan kompleksisuuden karsimisessa siksi, että kehittäjien pää täyttyy liiasta monimutkaisuudesta ja näin heikentää työtehoa. Toinen asia, jolla vielä kuitenkin on merkitystä, on mobiiliverkkojen rajoitettu nopeus (kaistanleveys): kannattaa pitää Javascript-tiedostot vaikkapa 100 -kilotavuisena, kuin antaa niiden kasvaa 2000 kilotavuun puhtaasti välinpitämättömyydestä.

Seuraavassa, osassa 3, aletaan rakentaa esimerkkiä.

 

Learning steve, an AI construction language for “breve” system

Reading Time: < 1 minute

Check out spiderland.org for more information. This AI framework allows you to
create creatures, involved in 3-D space of no limits, and evolving into higher creatures. It’s fun and really interesting way to understand programming and the blind watchmaker hypothesis into evolution. Not only does breve allow you to make the simulations, but it also renders them in 3-D and includes a physics engine, which are really precious. A physics engine knows about the interactions (in Newtonian framework) between objects; example: a collision causes the objects to either deform and/or move in a new trajectory.

Artificial intelligence is the branch of computing and mathematics which aims to make new kinds of intuitive understanding and realistic simulation of the world possible. AI can be applied in a variety of fields; from economics (behaviour of whole nations and the world economy), to understanding of basically very simple processes like that of a colony of very simple single-cell animals. AI has been a strong disciplinary interest for the academia since basically the birth of computers. Japan’s MITI was aiming to produce the 5th generation computers in 1990s, to allow for massive parallelism in a supercomputer grid. Its aims were to produce a better overall power of a networked computer system, compared to an ordinary isolated, high-frequency CPU & memory combinations.

I am looking forward to dedicating a good 30-60 minutes daily to spend playing with ‘breve’ and
really interested in how the program can help in simulating, say, the actions of a puma in a new habitat. Puma is almost an omnivore feline. Take a closer look at Wikipedia for puma (cougar), if you like.