perl ja irc-botti?

Reading Time: 2 minutes

Irc on edelleen päivittäinen “työkalu” ja vapaa-ajan huvitteeni. Hengailen muutamilla kanavilla; yksi on porukkamme virtuaalinen olohuone jo jostain 1990-luvun puolestavälistä saakka. Pari muuta kanavaa on myös erittäin kiinnostavia; jossa enemmän pelkästään WordPress / muuta tekniikkaläppää.  Oli vain ajan kysymys, milloin into tehdä botti kanavalle iskisi (irccasin vain 22 vuotta ennen tätä..)

On siis aika!

Ai tää on nyt niistä boteista?

Ei. Tää ei oo niistä droideista. Siirry eteenpäin [viittilöintiä 70-luvun kaapupropseissa].Nyt ei rakenneta bottia webbisivulle, vaikka ne ois kuinka in.Boteista on puhuttu tosi paljon viime aikoina myynnin automaation työkaluina. Irc-botti on periaatteiltaan aivan samanlainen: se on vain yksinkertaisempi ja arvattavampi, kuin myynnissä usein käytetyt tekoälyt, joilla pyritään tekemään ihmisenkaltainen keskustelukumppanit web-sivuille chattiin. Botin perusperiaate on:

  • liittyä kanavallekuunnella joko yksityisviesteinä tai kanavalle annettuja tekstikomentojatehdä komennon perusteella esimerkiksi webbiin kohdistuva hakubotti joko “keskustelee” takaisin kanavalle tekstinä, tai tekee IRC-protokollan määrittelemiä komentoja joista on hyötyä botin käyttäjälleusein botin käyttäjä jollain tapaa tunnistetaan, eli tuntemattoman irccaajat eivät voi käyttää bottia väärin omiin tarkoituksiinsa 

Irc-maailma koostuu palvelimista, jotka keskenään vaihtavat tilaa ymmärtämänsä “keskusteluavaruuden” tapahtumista: 

  • minkä nimisiä kanavia on olemassa

  • mitkä ovat kanavien ominaisuudet eli liput

  • kuka henkilö on milläkin kanavalla

  • mitä henkilöt (nick) sanoo

  • millaisia toimenpiteitä henkilö haluaa tehdä komennoilla

Avoin lähdekoodi ja bottien valmisreseptit

Irc-botti on hyödyllinen kapistus. Niitä saa valmiinakin lähdekoodina. Eikä ole yhtään huonompi idea käyttää hyväksi valmista koodia, jos mahdollista. Moni asia toistuu boteista toiseen lähes samanlaisena: harvemmin botin luojaa kiinnostaa esimerkiksi ns. ruohonjuuritason IRC-protokollaan tai muihinkaan protokolliin liittyvät asiat.Teknisesti botin ohjelmointikieltä ei rajoita mikään. Riittää että IRC-protokollan logiikka on suoraan toteutettu, tai se on otettu mukaan ohjelmaan pakettina / kirjastona. IRC:ssä kommunikoidaan tekstipohjaisella suhteellisen yksinkertaisella protokollalla. Teksti on 8-bittistä, eli Unicodea “vanhempi” perusmerkistö.  Sen sijaan botin ominaisuuksien eli hyödyllisten asioiden ohjelmoiminen on paljon jännempää! Se, että voi muuttaa ja mukauttaa bottia juuri itselleen ja porukalleen sopivaksi. Samoin testaus on olennaista: käyttäytyykö tuo ohjelma, niinkuin ajattelit suunnitteluvaiheessa? Joskus yksityiskohtien kanssa tulee paljonkin temppuilua. 

Pärjääkö botti tosimaailmassa?

Mikä IRC-verkossa voi koitua sitten botille ongelmalliseksi?

  • jos botti potkitaan kanavalta (kick)
  • joskus servereitä siivotaan, eli niiden prosessit tapetaan, jotta serverin (mahdollisesti ehtyvä) keskusmuisti ei loppuisi kesken. Kun botin prosessi tapetaan, botti luonnollisesti lakkaa olemasta. 

Mitä voit tehdä yllä oleville asioille?

Potkimiseen 

Serverin suhteen en ole varma. Kuvittelisin, että oman VPS:n liisaaminen eli virtuaaliserverin vuokraaminen on keino välttää mielivaltaiset prosessin tappamiset. Hinta on hieman korkeampi kuin satunnaisesti jonkin palvelun kylkiäisenä tulleelle serverikapasiteetille, muttei mitenkään huimasti. 

Muutamia pointtereita tarpeellisiin lähteisiin

My Tips for a Professional Developer

Reading Time: 5 minutes

Purely coming from my experiences so far.

I’m a geek. I’m a programmer. I hack away, I’ve always done code. From some point onward, I also started doing code for money into real industrial and business applications.

It was a fantastic moment to really grasp that what had been merely a pastime, could be turned into my trade. I enjoyed software development ever since.

The elements of change can be categorized easily:

  • things that stay the same
  • new stuff
  • skimming, bubbling, trending and waning stuff

Things that stay the same

Computers essentially still are programmed by making them follow instructions, to manipulate bit-based objects. Things that are made from a series of 0 and 1 bits.

Did you know that most of the surface area, cost and complexity of CPUs is due to massive parallelism? The number of gates, total cumulative “vias” (electron conductors) and related power consumption is due to the fact that it isn’t the basics of computation that have changed, but the sheer “volume” or pipeline that the processor crunches nowadays! Essentially a CPU nowadays does serial computation, but in massive scale – and with some snazzy tricks to avoid calculation of futility. Caching is the technology that fetches a result that is already known at the time the computing instruction hits the execution pipeline.

U canst

What I’m trying to say is that even though you might think OMG! I could never understand CPUs of modern computers, I’d say that’s not true. Zooming in, down to the elementary parts you would still find very familiar concepts: registers, simple microcode (pieces of a actual machine code instruction). The computer’s guts, so to speak, are of the type: IF something THEN do something, ELSE do something else. IF-THEN-ELSE. Add to that a capability to jump (branch execution to other place), add two numbers together, and so on – it’s what makes your machine tick. The rest is performance glitter.

What the software industry is aiming is a few things besides technology development per se:

  • managing complexity of a software project, sometimes reaching 100,000s or even millions of lines
  • handling the blame game and risks properly
  • verifying and testing the quality of software
  • keeping software development costs at bay
  • if possible, keeping the margins (profit) by applying blue ocean strategies
  • avoiding cardinal mistakes of doing an app of tech that no one will ever use (or pay for)

Meta: The process side of software engineering

With more experience under the belt, I got great experiences from methodologies to cope with project complexity, team work, splitting development to many members, solving problems together, and continually improve the way the whole team works.

This is a recollection of things that I’ve encountered. Ideas, methodologies, good and bad ones. Things that worked for me, some that din’t.

I’m not particularly an advocate of any specific one toolbox, whether it is a project methodology or a piece of the tech stack.

Enjoy the silence

You might have periods of silence in the project, and especially during daily schedule. Enjoy. These are often the moments where intense development and raw writing work happens. Coding is something that takes different turns depending on the microtask at hand; sometimes you are basically writing quite simple snippet of code, where you don’t have to hold many constraints or guidelines in your head at the same time. At other times, you’re doing a leap forward in some critical portion, where a lot of “things hang in the air”, and making it all spit out as code is a lot more nerve-wracking. People counter often the physical noise with means such as noise-cancelling headphones. These are really ways to do stuff. And a reminder to all fellow coders: even though we might perceive someone is merely listening to good music and having fun, remember that inside what happens might be a intense concentration and trying to get a complex thing to fit.

Turning fear into curiosity

Frustration can be a powerful force. Sometimes upon initial impact with a project, a so-called handover, there can be friction; you might be looking at a work worth up to several years, when you are entering in midst of a project. There’s a lot of tacit knowledge also present, decisions having been made. A new project being handed over is like a shapeshifting blob of stuff; you’re struggling first to get a overview and familiarize yourself with possible any new tech that comes up.

Don’t be intimidated by initial frustration. It usually turns out fine! Keep asking those dummy questions and keep an eye for possibilities to start chiming away with the code. Usually when you do changes and additions, things start to roll at once.

  • identify your emotions
  • identify the flow and connections between emotions; did you get frustrated at something, a process, someone particular; at a way of things done, or something that you think should definitely be done?

Ivory Tower – Old Systems Plague

Some large organizations have problems in fallout of obsolete technology. Large HR / workflow systems implemented years ago seemed like a great idea; now, they’re outdated, clumsy to use, and have little if any real positive effect on personnel. Yet no-one seems in position to nudge a change. This is a typical situation that you might encounter.

My tips:

  • keep your head cool
  • try to find other kinds of users besides yourself; what do they have in it? Someone surely knows how to motivate using the system, otherwise it would’ve most certainly been dumped
  • when there’s a chance, be part of the changing force that can make things better

Learn to surf on the cutting edge

In our profession, things rarely are “ready”. That means:

  • you will be using software to make software
  • software contains always some bugs
  • => this means that your tools are not perfect!
  • some of those bugs will be visible to you, too
  • you will get irritated by the bugs
  • you can also control how much you let the bugs irritate you, and
  • file a bug report. Or even better: make a patch, and submit that (if the tool is open source and hosted somewhere publicly)

This trend IMHO has stayed essentially the same. The microarchitecture of our tooling has been more finegrained – so on average we’re doing software composed of many more packages, than we used to.

Software stacks – 50000 ft view

Some software stacks might take considerable time to get ready for work. We might be talking about a day or two, typically. There’s some trial and error typically in the process of setup. The more cutting-edge stuff you use, you’ll find that there’s often no single “dogma” of how to do even such a thing as complete setup. It just takes a bit of getting to know the stuff. Explore the options, try to also read first-pass without interruptions and as much as you’d like, it might be better to resist the temptation to go hands-on immediately. So: read. Then start doing, once you got a grasp of the big picture. Otherwise it’s really easy to get stuck midway, and actually wonder how you can undo your half-baked installation.

This is something that is best tackled with patience.

I’ve gone through maybe 20-30ish stacks at some depth. The biggest change that I perceived is that during the last 20 years, rise of open source dogma made a refreshing change in the sense of involvement. Whereas stacks used to be “professional toolboxes” introduced by some big corporation, nowadays stacks are a living project where individual contribution is often appreciated, things move faster, and there’s a better chance of actually reaching a live person to ask about for advice.