Yoast -lisäosa Jukkasoftin blogiin

Reading Time: < 1 minute

Toteutin pitkäaikaisen unelman: WordPress-blogin Yoast SEO -lisäosa käyttöön. Yoastin on sanottu olevansa alansa parhaimmistoa. Yoast sisältää paljon toiminnallisuutta. Se tekee paljon asioita automaattisesti, ja toimii mukavan opasteellisena apurina koko ajan blogiartikkelin kirjoittamisvaiheessa. Yoastin voi nyt Gutenberg-editorissa myös pitää kätevästi hyvin passiivisena, jos ei halua jatkuvasti katsella neuvoja.

Kuten kaikki tehokas teknologia, Yoast vaatii hieman opettelua. Suosittelen esimerkiksi tämän sivun lukemista.

Yoast käytännössä mm. helpottaa sivuston teknisen rakenteen ylläpitoa niin, että blogi on paremmin hakukoneiden ymmärrettävissä. fcde14bc-36f2-417e-bdca-c1b8dc25042a-713-0000004c8eef532c_file.jpgSEO (search engine optimization) on iso kirjo erilaisia asioita, jotka käytännössä vaativat sekä funtsaamista että raakaa työtä.

Tutustun lähiaikoina lisää Yoastiin, ja mielenkiintoisten piirteiden ilmestyessä pistän uutta artikkelia tänne!

Non-functional items in Branding through software

Reading Time: 2 minutes

“How the perception of quality of software is affected
by other merits than core technical features and the code”

IMG_7100

– sales techniques
– initial approach and product presentation
– management of customer expectations
– matching the sales process and its promises with operations
– simple and effective communications in presenting solutions

Software in-line documents: comments lines

Some of the g2g communication is within source code comment lines.

– comments being to the point: don’t blabber
– aim your comments covering 2-10% of total line count (SLOCs)
– comment contents should be useful for developer or other stakeholder (designers, users involved in customizing)
– positive points: score by checking your commentary is not bloated, repetitive, unnecessary

Quality of the payload code

linted with appropriate tool
– advanced: metrics with SonarQube or other dashboarding tools
– make sure there’s really an active process to make sure code stays well maintained / “hygienic”
– don’t fall to the “just letting metrics be”, do TAKE ACTION. Let my experience speak: technical debt never goes down automatically.
– scanning using programmatic methods
– human perception of the code: ask your colleague for code review
– self-explanatory, or perceived throught architectural documentation?

– in open-source projects, code quality comes in 2 senses:
– the actual code (payload)
– comments
– other possible artefacts that are in the repository

Do code Commit patterns matter?

– commit pattern means the temporal distribution of developer’s effort
– a commit means “uploading” to the central repository part of new code
(or fix) from a developer’s computer
– does the client see and care about something in when and by whom the
‘git commits’ are done?
– there may not yet be actually any hard science on the research of commit
patterns and how they affect code quality
– different software corporations and/or teams might have conventions on this

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!

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ä.