Git server and Jira on Debian

Nothing special, just yet another "I've done it this way" installation log.
But hey, did you know that the word "blog" comes from "web log"? So here it is :D.

Base OS

Start from a minimal Debian installation.

Git server

Start from this howto.

It's not 100%, because some config formats have changed since then, so here are the differences:

Repo name

Where it says repo1.git, choose your own repo name. Choose a descriptive one and save the constant need for explanation.

Git config files

It uses a separate /etc/gitdata, I found /opt/allgit more convenient:

* It's also not publicly accessible
* All related files are at the same place

So I put gitusers.passwd and the certificates also here.

The SSL certificate

When creating the cert as the howto tells to, openssl will ask about the identity for whom to create the cert. For the CN (Common Name) enter the public hostname of your server, the rest is up to you, technically it doesn't matter.

Besides, the command in the blog indeed generates a self-signed cert, but also marks it as a CA cert (because that it is).

This is fine, but Apache will dump warnings in the log:
AH01906: <your public hostname>:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)

Normally you would have one cert and its private key for your server, and one cert (without its priv key) from the CA authority that testifies for your server cert.

Here you have one certificate and the private key that belongs to it, that's all, and this certificate plays
both roles: it acts as a server cert, and also a CA cert that has signed your server cert ('self-signed', it is).

Apache modules

The actual command is a2enmod ssl cgi alias env.

Apache site config

cp default-ssl mygitdomain.com.conf

Don't forget to append .conf!

Then, you'll need a bunch of small fixes:

* An enclosing VirtualHost definition
* Logfile name: we'll also run Jira, Confluence, maybe more, so a domain-related log filename is more descriptive than the git-related one used by the howto

So here is the site config:
<VirtualHost _default_:443>

        ServerName <your public hostname>
        ServerAdmin webmaster@localhost
        ErrorLog /var/log/apache2/<your public hostname>.log

        SSLEngine on
        SSLCertificateFile    /opt/allgit/mygit_ssl.crt
        SSLCertificateKeyFile /opt/allgit/mygit_ssl.key

        # ==== Generic public space

        DocumentRoot /opt/allgit/public

        <Directory "/opt/allgit/public">
                Options Indexes FollowSymLinks
                AllowOverride None
                Require all granted
        </Directory>

        # ==== for the git repo

        SetEnv GIT_PROJECT_ROOT /opt/allgit
        SetEnv GIT_HTTP_EXPORT_ALL
        SetEnv REMOTE_USER=$REDIRECT_REMOTE_USER
        ScriptAlias /allgit/ /usr/lib/git-core/git-http-backend/

        <Directory "/usr/lib/git-core/">
                AllowOverride None
                Options +ExecCGI -Includes
                Require all granted
        </Directory>

        <LocationMatch "^/allgit/repos/.*$">
                AuthType Basic
                AuthName "My Git Repositories"
                AuthUserFile /opt/allgit/gitusers.passwd
                Require valid-user
        </LocationMatch>

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

A public http space

Your git repos will be accessible as https://<your public hostname>/allgit/repos/some_repo.git, that's fine.

But you may need a generic https://<your public hostname>/<whatever> space, at least for not displaying the default Apache placeholder.

mkdir -p /opt/allgit/public

Whatever you put in this folder, it'll be accessible like the generic link above.

About the Certificate Verification Error

A self-signed cert tells the client that you are who you say you are, just because you say so.

If the client accepts you as trustworthy, then believes what you say, that you are who you say you are :). If he accepts you as trustworthy, that is, otherwise your browser will throw those 'security alert' windows at you, and the commandline clients (like git) will just exit with an appropriate error.

So, you must add your CA certificate to the 'trusted' group at your client.

Disabling the cert checks for git

The howto tells you can, and it indeed would work, but believe me, it's a bad idea.

Anyway, here's the command: git config --global http.sslVerify false

However, you'd rather add the cert to the client's trusted group, it's not that complex.

Adding your CA certificate to the client's trusted group

The client has a folder in which it contains all the CA certificates it considers trusted, you shall

put your CA cert (in this case, the cert), but the filename must be a special one instead of mygit_ssl.crt.

Why (skip this if not interested)

There is a technical reason for it: When the client receives a cert from a server, it wants to check whether it was signed by a trusted CA, so theoretically it should look up all the trusted CA certs and check whether it has signed the server cert or not. This is time-consuming, because there can be quite a many of trusted CA certs.

On the other hand, if the filename of the required CA cert could be identified by some means, then there would be no need to check all the CA certs, it would be enough to read just the required one.

This is achieved by a checksum-like trick: for all CA cert a checksum is calculated from the name of the authority they represent, and this checksum gives the beginning part of the filename.

(NOTE: I say checksum and name of the authority, but in fact there's a more complex hash algorithm used and it's applied to the full Distinguished Name of the issuer, not to the human-readable one. Anyway, the principle is the same.)

So when the client sees a server cert, it just reads the name of the authority that has (allegedly) signed that server cert, calculates that checksum for it, and if there indeed is a trusted CA cert representing that authority, its filename will begin with that checksum, so the client must check only a few trusted CA cert files instead of all of them.

Why few and not just the one? This is a checksum, necessarily shorter than the information from which it is calculated, so theoretically there can be more than one CA authorities whose name gives the same checksum.

Therefore the actual name of the file is like <checksum>.<idx> where this idx is just an incremental number, starting from 0, so if there are two CAs whose names give the same checksum 12345678, then their filenames will be 12345678.0 and 12345678.1 respectively.

How to get this filename

cp /opt/allgit/mygit_ssl.crt /opt/allgit/public/$(openssl x509 -noout -hash -in /opt/allgit/mygit_ssl.crt).0

ls -l /opt/allgit/public/

Now we've copied our certificate to the publicly available space (it may be published, just the private key is to be kept secret), with an appropriate name.

On the client you may download it with a browser like https://<your public hostname>/12345678.0

What to do on the client side

Create a folder if it doesn't yet exist: mkdir -p /etc/ssl/certs, download the cert file into it.

Make it world readable but writable only for the owner:
chmod 644 /etc/ssl/certs/12345678.0

make it owned by root:
chown root:root /etc/ssl/certs/12345678.0

And finally git to use it system-wide:
git config --system http.sslCAPath /etc/ssh/certs

This way you configured it for all users on the client machine.

If you are just one user, and don't have root access, then create the folder as ~/certs and

tell git to set only your global config (instead of the system-wide one):
git config --global http.sslCAPath ~/certs

Jira

A few words in advance.

Jira will set up itself as an independent web server that listens on http://localhost:8080/whatever, that is, separate port, no encryption, and everything on this 'host:port' is assumed to belong to Jira.

But our server is not dedicated just to it, we'd like to access it at https://<your public hostname>/jira/whatever, that is, standard https port, SSL encryption, and only the part after /jira belongs to Jira.

This is possible, but we need some configurations to change a bit.

The second issue is that Jira and the IPv6 support of Debian are not fully compatible, so we'll need to disable IPv6.

I've tried the mentioned _JAVA_OPTIONS setting, it didn't work.

The symptoms were: after installation Jira starts fine and listens on 8080, but if I stop and restart it

as a service (or manually, doesn't matter), it starts, but doesn't listen on 8080.

So, roll up your sleeve, take a sip of your coffee, and let's begin :).

Disable IPv6

Edit /etc/sysctl.conf as described here.

In addition, edit /etc/ssh/sshd_config and change AddressFamily any to AddressFamily inet (uncomment it as well, if it's still commented out).

Then reboot the server - sorry, no way to do it online.

Set up Apache to act as Reverse Proxy

Reverse proxying means that technically the Apache will receive the incoming https://.../jira/whatever requests, but instead of processing them by itself, it'll pass them on to Jira, with rewriting the URLs as needed.

There is a nice description of the concept here, but as usual, it's not 100% applicable, things have changed a bit since then.

Some more apache modules

a2enmod proxy proxy_http proxy_connect

Edit /etc/apache2/mods-enabled/proxy.conf and uncomment the Proxy block.

Site config

Edit /etc/apache2/sites-available/<your public hostname>.conf again:

<VirtualHost _default_:443>

    ...

    # ==== for Jira

    ProxyRequests On

    ProxyVia On

    <Location "/jira">

        Options Indexes FollowSymLinks

        AllowOverride None

        Require all granted

        ProxyPass "http://127.0.0.1:8080/jira"

        ProxyPassReverse "http://127.0.0.1:8080/jira"

    </Location>

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

This tells Apache that whenever it gets something that starts with /jira, it shall pass it on

to Jira, by rewriting that /jira to http://127.0.0.1:8080/jira (keeping whatever follows in the URL).

NOTE: By default Jira will expect http://127.0.0.1:8080/, so we must reconfigure it to use the /jira path instead of just /.

Restart Apache

Easy to forget, annoying to debug :).

systemctl restart apache2

Install Jira

Just follow the official howto. For the impatient, here is the current installer for linux/x86_64.

The default installer method is fine (no need for custom), only at the last question, whether it shall start Jira right away, should you say 'no'.

Configure Jira to use the '/jira' path

Open this howto, and see 'Step 1 Configure Tomcat', and '2 set the context path' within it.

The other sub-steps are NOT needed, they refer to a different situation, when the Jira server is completely separated from the internet, which is not the case here.

Start Jira

The moment of truth :D.

systemctl start jira

top

Wait until it settles and the load goes down (it does some initialisation before actually starts listening), then check if it managed to start up:

ps axufww | grep java

If you see a multi-line crap of a command that starts with /opt/atlassian/jira/jre//bin/java, you're halfway home.

If not, then see the logs in /opt/atlassian/jira/logs/, but they are not the most straightforward kind, prepare for heavy googling and you may as well open stackoverflow.com too.

Check if it listens for incoming connections:

netstat -4nlp | grep 8080

If you see the process above (like 1118/java), your Jira is up, so if Apache passes some requests to it, it may even work.

If you seen nothing here, regardless of the fact that the Jira process is running, you're deep in Trouble County. Check if IPv6 is indeed disabled (ifconfig shall show no inet6 addresses).

If it is, then I'm out of ideas, and I bet the logs won't help much either. Google, SO, try some magicks, some may even do the trick, provided that the rest hasn't wrecked your system to crap by the time you find the good ones... If you ran into it and found something useful, please leave a comment with the details (OS version, Jira version, the magick that killed the beast, etc.) for the rest of us!

PostgreSQL

You'll need a postgres to store the data for Jira and Confluence, and you may start with the official howto. Almost 100%, as usual.

As of Postgres config, as long as you want to access the DB only from localhost and only by users

whose unix username matches the database username (for Jira this is the case), its the default config will suffice.

Things that differ from the howto:

Version

Now it's 9.6 instead of 8.4.

Enable and start

Don't forget to enable and start the DB after installation:

systemctl enable postgresql

systemctl start postgresql

DB User

As of 9.6, the createdb command won't ask you questions, but expect the options for the role as

commandline options.

The right to create DBs is given by -d, so your command is createuser -P -d jira .

If you messed up, just dropuser jira and try again.

Choose a nice random password, it'll be needed only once, when you tell it to the Jira setup.

(My favourite password generator is the pwgen package: pwgen --no-numerals --no-capitalize 12, it dumps a screenload of more-or-less intelligible but still random passwords, pick one and use it. Far better than 'Jira!123', maybe a bit weaker than correct horse battery staple, but still meets most of the stupid password criteria...)

Jira setup

The final steps can be done via your browser.

On your client, open https://<your public hostname>/jira, you shall get a nice Jira setup page.

If you don't, check the apache logs in /var/log/apache2/<your public hostname>.log on the server, there's most probably some typo in the apache proxy setup (spaces and slashes do make a difference there!)

On the Jira setup page choose to do it for yourself, choose an external DB, set it to Postgres,

host=127.0.0.1, port=5432, db name is the db name you created, username is 'jira', password is the

nice random password you've chosen, Test DB Connection.

On the next screen set an App Title, and set the Base URL to https://<your public hostname>/jira!

That's all, you're done :D !

"Mérnök"

Mottó: "Ha az építészek úgy építkeznének, ahogy a programozók programoznak, akkor az első k.... harkály romba dönthetné az emberi civilizációt!"

 

 "Mérnök" és "ipar" vs. IT

A hétköznapjaink tele vannak az IT gyarlóságaival: már megint lefagyott az X app, az Y böngésző eszi a memóriát és rendszeresen újra kell indítani, a Z oprendszerben újabb kritikus sebezhetőséget fedeztek fel, és így tovább.

Ugyanakkor szintén naponta találkozunk az IT diadalaival: újabb képfelismerő rendszert fejlesztettek ki az X cégnél, az Y egyetemen tovább jutottak a szövegértési rendszerekkel, a Z technológia instant képi kommunikációt tesz lehetővé fillérekért, satöbbi.

Ilyesmiket valahogy sokkal ritkábban hallani a klasszikus mérnöki területekről, pl. a gépészet, vegyészet, villamos- és építészmérnöki  tudományok tájáról. Vajon miért?  Van-e netán összefüggés a kettő között, esetleg valami közös ok, amelyikből ezen két sajátosság ered?

Vegyük kicsit szemügyre először a hagyományos mérnökök munkájának azon vonásait, amik az IT-ben másképp vannak.

Hosszú lesz, de egyrészt úgyis munkaidőben vagyunk :), másrészt pedig szükség van a pontos képre.

Aki nagyon türelmetlen, az menjen a végére, van ott egy egyflekkes összefoglaló is :).

A hagyományos mérnöki tevékenység

Szabványok használata

Egy gépészmérnök csak a legszükségesebb esetben tervez új komponenst, ahol csak lehet, igyekszik már létező, szabványos, 'katalógusból rendelhető' elemekből tervezni, építkezni. Ezt diktálja egyrészt a gazdaságosság, hiszen így a kész rendszer tulajdonosának a későbbi pótalkatrész beszerzésénél könnyű a dolga, nem kell egyedi gyártmányt újragyártatnia, de ugyanebbe az irányba hat a megbízhatóság is, nevezetesen egy komponens csak akkor kap forgalomba hozatali engedélyt, ha annak van érdemi specifikációja (a paraméterek várható érteivel, szórásával, üzemi és extrém minimumával és maximumával), és ez rendszeres szúrópróbákkal ellenőrizve is van. A tervező mérnök tehát ezekre építhet, az ezen modulok megvalósítási problémáival nem neki kell megküzdenie, azt már azok tervezői és gyártói megtették.

Ez olyannyira értékes szempont, hogy épeszű keretek között az anyagtakarékosságot és a méret-optimalizálást is felülbírálja: Ha valahová a méretezés szerint minimum 11.712 mm vastag csavar kellene, akkor nem esztergáltatunk pontosan akkorát pontosan a szükséges darabszámban, hanem betervezünk 12-est, vagy rátartással akár 14-est, amiből fél óra alatt lehet venni kilószámra fillérekért bárhol.

 

Iparági előírások

Egy villamosmérnöki tervezésnél konkrét előírás van arra, hogy milyen felhasználásra milyen fajta vezetékek használhatóak, azokból milyen terhelésre milyen minimum vastagság van előírva, és milyen környezetben milyen szigetelési és érintésvédelmi intézkedéseket kötelező megtenni.

Egy épületvillamossági terv nem kap jóváhagyást, ha ezen előírásoknak nem felel meg, és jó okkal: ez garantálja az üzembiztonság első, legalapvetőbb szintjét (amire aztán épülhet a többi).

Egyrészt tehát ezek számítgatásával sem kell bajlódni (és óhatatlanul elrontani egyet az ezer, vagy akár csak a tízezer esetből), valamint ha más munkájához csatlakozik a miénk, akkor építhetünk arra, hogy ő is ezen elvek szerint dolgozott.

 

Szabályozott folyamatok

Ahhoz, hogy egy termék forgalomba kerülhessen, pontos specifikációt kell adni arról ('mit vállal?'), a felhasználási paramétereiről ('milyen körülmények között vállalja?'), a gyártás mérőszámairól és a folyamat ellenőrzési pontjairól ('honnan tudhatjuk, hogy tényleg teljesíti a vállalást?'), és szükség van a teljes felépítési és működési leírásra is ('hogyan teljesíti a vállalását?').

Azt, hogy közben más problémákat nem okoz, azt nem kell külön igazolni, mert azt az iparági előírások betartása hivatott garantálni.

Az emögötti koncepció az, hogy aki a mi termékünket használja építőelemnek az ő termékéhez, az ugyanúgy számolhasson a mi vállalásunkkal, mint ahogy mi is számoltunk a mi építőelemeinkével.

 

Összefoglalva

A mérnök munkája nem izgalmas és újdonságokkal teli, hanem 'csak' a derék, jól végzett tevékenység megelégedettségét nyújtja: a mérnök jól bevált, kipróbált, megbízható és ellenőrzött elemekből és technológiákból építkezve biztosít a feladatra stabilan alkalmas, kipróbálható, megbízható, ellenőrizhető megoldást.

Ez nem a kreativitás hiányát jelenti, hanem inkább olyan szabályok betartását és olyan hozzáállással végzett alkotást, ami terméket eredményez, azaz valami olyasmit, amit nem-mérnöki felhasználó is tud a megadott célok elérésére használni.

Nem magunknak tervezünk, nem a világ szépségére, nem a tudásunk csillogtatására, hanem egyes egyedül azért, hogy a megrendelő igényeire hatékony és fenntartható megoldást  nyújtsunk.

Az ilyen, terméket előállító tevékenységet hívjuk iparnak.

 

A kutató / fejlesztő / konstruktőr tevékenysége

Ők azok, akik  új, soha nem látott dolgokat találnak fel vagy fejlesztenek ki, akik olyasmiket hoznak létre, amikre más még nem is gondolt.

Ez persze teljesen más megközelítést igényel, mást nyújt és mások a lehetőségek, és mások a problémák is.

 

Nincsenek keretek

Feltalálni valamit kétségtelenül izgalmasabb a mérnöki munkánál, és kötetlenebb is, hiszen új területről lévén szó, még nincsenek előírások, nincsen 'keret', amihez igazodni kellene.

Van, hogy egy prototípus elektromos kapcsolásnál még az érintésvédelem is csak minimálisan van megoldva, hiszen a dolog kísérleti jellegéből nem kell olyasmikkel foglalkozni, hogy pl. mi történik, ha a berendezést kinti hidegből meleg helyiségbe viszik, és így a burkolatán pára csapódik ki.

Az érem másik oldala, hogy olyasmi sincs, amihez igazodni, amire építeni lehetne, tehát a konstruktőr csak magára számíthat, hiszen olyasmikre használ mindent, amire annak tervezői nem gondolhattak, neki semmi se garantált, minden előfordulhat.

Az első, még kísérleti turbinás hajtóműnél sem lehetett előre tudni, hogy hogyan fog viselkedni a tengely anyaga a konstans magas hőmérsékleten a 20 kHz körüli mechanikai rezgés hatására, mert ilyennek azelőtt még nem volt anyag kitéve.

 

Nincs termék sem

Ennek megfelelően viszont az így előállított dolgok, még amikor működnek is, akkor sem tekinthetők terméknek, hiszen nem ismeretesek a korlátaik, nem lehet rájuk érdemi garanciát vállalni, így tiszta lelkiismerettel nem lehetne a felhasználóknak kiadni őket. Nem beszélhetünk tehát közvetlen haszonról sem, nincs megtérülés sem, optimalizálni sincsen mire.

Szigorúan nézve a kutatás-fejlesztés (K+F) egy pénznyelő, amit bizonyos intézmények azért tartanak fenn mégis, hogy az így előálló ismeretekből később, hosszabb távon lehessen gyümölcsözőbb technológia.

A félvezető lézerek tömegtermelése előtt az optikai adattárolás is csak egy érdekes laboratóriumi kísérlet volt, amihez rezgésmentes környezet és drága kísérleti eszközpark kellett; a lehetőséget igazolta ugyan, de mindennemű gyakorlati haszon nélkül. Az majd később jött, amikor már kialakult a lézerdiódák olcsó gyártástechnológiája, amihez viszont pont az optikai adattárolás bizonyított lehetősége adta meg az indíttatást.

 

Más tehát a cél

A cél tehát általában valamely elv vagy konstrukció működőképességenek az igazolása, valami nagyon korlátozott feltételek között ugyan, de működő prototípus előállítása, amiből későbbiekben sok-sok munkával ipari technológia is válhat.

Bár a kutatás által létrehozott működő prototípus tulajdonképpen nem a cél, hanem igazából csak a rajt: abból, ami valamilyen körülmények között egyszer működött, pontosan meg kell határozni a szükséges feltételeket és az elvárható működés paramétereit, és megbízható, reprodukálható, a belelátás és belenyúlás igénye nélkül felhasználható építőelemet, technológiát kell belőle csinálni, ami a fejlesztés feladata.

 

Összefoglalva

A konstruktőr egy sejtésből új technológiát állít elő, vajmi keveset törődve közben rend- és módszerességgel, kiszámíthatósággal, de ez szükséges is ahhoz, hogy az eddigieken túlmutató, új dolgok jöhessenek létre.

Azon dolgozunk, hogy megmutassuk, hogy a dolog megoldható, működésre bírható, hogy lehetséges. Nem valami konkrét célért, hanem az új lehetőségek feltárásáért.

Az ilyen, lehetőségeket feltáró tevékenységeket hívjuk kutatás-fejlesztésnek.

 

A kontár 'Mekk mester' tevékenysége

És persze vannak azok, akik ötvözni próbálják a mérnöki munka megoldás-központúságát a feltalálói munka kötetlenségével, és önfeledten gányolnak bármit és mindent a megrendelőnek, tekintet nélkül annak a biztonságára vagy fenntarthatóságára.

Sokszor pont ezeknek a félmegoldásoknak az előnyös tulajdonságait ('olcsó!', 'kicsi!') használják reklámként, az ezért beáldozott egyéb tulajdonságok említése nélkül, ezzel letarolva a keresletet a korrekt(ebb) megvalósítás elől.

A kontárság kicsiben azzal kezdődik, hogy az illető a réz burkolatot vascsavarral rögzíti (olcsóbb, csak fokozott korróziót okoz), nagyobb léptékben azzal folytatódik, hogy egy kapcsolóüzemű tápegységből kispórolják a szűrést és a túlfeszültségvédelmet (olcsóbb, csak hajlamos leégetni a táplált berendezést), és kicsúcsosodni a sajtóból ismeretes autóipari botrányok környékén szokott.

 

Összefoglalva

Amikor valaki az igénytelenség, a hozzáértés hiánya vagy a rövidtávú haszon növelése miatt indokolatlanul tökéletlen, csökkent működőképességű vagy minőségű kísérleti vagy fejlesztési szintű dolgokat kész termékként tálal, akkor az nem termék, hanem megtévesztő selejt.

Hál'Istennek hivatalos kereskedelmi forgalomba csak nagyon korlátozottan jut tovább az ilyesmi, köszönhetően a kötelező norma-kontrollnak, legalábbis a világnak ezen a részén, úgyhogy az ide tartozó dolgokat inkább a kisipari mókolásnak és a meggondolatlan dzsunka-importnak köszönhetjük.
Nem szabad viszont lebecsülni a sok apró kókányolás hatalmát: ha egy piac 99%-át ilyen teszi ki, akkor aközött elvész az 1% normális, és ez válik normává.

Az ilyen, kontár selejtet termelő tevékenységet pedig egyéb iránt gányolásnak hívjuk :).

 

Az IT szektor jelen állapota

A hosszas felvezetés során meghatározott fogalomrendszerrel tehát hová sorolnánk azt, amit az IT terén manapság látunk? Haladjunk inkább sorban, nézzük először az objektív tényeket.

 

Szabványok

Nagyon kevés a szabványosított dolog. A TCP/IP például az, és nincs is vele gond. A HTML például nem az, és pont annyira lehet is építeni a kezelésének a mikéntjére.

A szabványok velejárói, hogy pontosan leírják az általuk meghatározott dolog mérési pontjait és az azokra megfogalmazott előírást, és ennek megfelelően egy TCP/IP stackről el lehet dönteni, hogy úgy viselkedik-e, ill. hogy megbízható-e, vagy sem.
Az újabb keletű dolgok, amiknek a specifikációja (ha van) erősen használja a 'might/may/shall/should' fogalmakat, azok nem szabványok, egy ilyesmi olyan helyen tud meglepetést okozni, ahol nem is várná az ember.

Meglepően hatékony volt annak idején viszont pl. a JavaEE terén a referencia-implementációval történő specifikálás (glassfish): ami azzal működött, az szabványos, ami nem, az nem.

Lehet, hogy nem a legjobb megoldást fogalmazta meg, de teljesen egyértelmű volt, tehát lehetett rá építeni. 

Iparági kontroll

Nincsen. Konkrétan semmilyen nincsen.

Forgalomba kerülő autót csak úgy tervezhetek, ha megvan a szükséges végzettségem, ha a terv átmegy számtalan ellenőrzésen, és azután a null-széria is kiállja a tényleges törésteszteket.
Szoftvert ezzel szemben bárki fejleszthet, publikálhat és hozhat forgalomba, és a készterméknek sem kell a legkisebb teszten se megfelelnie.

Nem hivatalos irányelvek vannak (SOLID, CleanCode, stb.), amiket általában csak akkor szokás megszegni, ha valakinek épp úgy jön kézre, és perse erre vonatkozóan sincs semminemű ellenőrzés.

Ez különösen azért problémás, mert hiába tartaná magát ehhez valaki, ha az általa használt építőelemek megbízhatatlanok: az eredmény is az lesz.

 

Termék-szemlélet

Szintén hiánycikk. Ritka az olyasmi, amikor egy program teljes és használható dokumentációval érkezik, egyrészt mert a szabványok hiánya miatt nehéz is lenne megfogalmazni pl. azt, hogy mit is értünk a 'HTML-t jelenít meg' alatt, másrészt pedig általános érvként használatos, hogy 'ott a forrás, ha érdekel, nézz bele'.

Most képzeljük el, hogy veszünk egy autót, a leírása egy reklámprospektus, és amikor megkérdezzük, hogy milyen üzemanyag kell bele (oktánszámot is beleértve!), akkor azt kapjuk válaszként, hogy 'hát szedd szét a motort, aztán olvasd ki belőle, hogy mit mennyire tolerálna'...

Kutatás-fejlesztés?

Igen, sajnos a termékek nagy része (a pénzeseké is!) erősen prototípusnak mutatkozik. Működik valahogyan, valamikor, de nincs is célba véve, hogy ez vagy általánosabb legyen, vagy legalább ismerjük meg a peremfeltételeit.

A nyílt forráskódú világ pedig szinte teljesen ilyen, befejezett, vagy legalábbis funkcionálisan teljes verziójú dolgot nem találni, a dokumentáció és support pedig ritka, mint a fehér holló.

És ezzel így még semmi baj sem lenne!
Mármint ha emellett lenne szoftver-termék és -ipar is, azaz a forradalmian ötletes barkácsvívmányok mellett lennének alternatív lehetőségként konzervatív, bejáratott, kevesebbet ámde azt stabilabban tudó programok is.

 

Gányolás?

Hajjaj. Fejlesztő lehet bárki, aki gépelni tud, és be tudja copy-paste-elni a 'git commit; git push' parancsokat...
Árulkodó, hogy a pl. stackoverflow-n feltett kérdésekre a válaszok hány százaléka követi a 'hát biztosan nem tudom, de nekem így működött'-sémát.

El lehet képzelni, hogy milyen minőség és megbízhatóság kerül ki egy olyan fejlesztő keze alól, aki nem ismeri az általa használt eszköztárnak még az általa használt részét sem. Nos, pontosan olyan...

 

A felhasználói kultúra

Meglepő, de nincsenek elvárások! Ezen a téren teljesen általános és elfogadott az igénytelenség, értve ez alatt az igényektől való mentességet, azaz a felhasználók teljesen normálisnak tekintik, hogy

• egy program lefagy
• újra kell indítgatni
• nem tudni, hogy mit csinál (mit hová továbbít)
• adatokat ad ki kívülállóknak
• a felhasználó tudta és engedélye nélkül változásokat eszközöl

Ugyanez tapasztalható az információkkal kapcsolatban is. Nem lepődik meg senki, ha

• egy weboldalon nem az van, mint amit a címe mond
• egy kereső olyan találatokat ad ki, amiken nincs is rajta a keresett dolog
• kéretlen reklámokkal bombázzák az embert
• a kapott információ pontatlan, idejétmúlt, és nincs felelőse (se dátum, se forráshivatkozás)

Közben az általános panaszkodás ellenére mindenki továbbra is használja a kifogásolt programokat/szolgáltatásokat/forrásokat, amikor pedig pl. háztartási gépek kapcsán hasonló esetben nem hogy kidobná azt, de attól a gyártótól mást se venne még egyszer, még akkor sem, ha nincs igazi alternatívája.
Megszoktuk, elfogadtuk, és már teljesen természetesnek vesszük, hogy a szoftver megbízhatatlan és az adat hamis, és nem vagyunk hajlandóak még arra sem, hogy 'a pénztárcánkkal szavazzunk'.

Ahogy a szoftver-világban régen használatos 'stable/unstable/testing' felosztás kihalt, úgy vette át a helyét az 'örök béta' hozzáállás.

Ha az autónktól tapasztalnánk ehhez hasonló üzembiztonságot, akkor attól a gyártótól lábtörlőt se vennénk többé, azt viszont szó nélkül lenyeljük, hogy a telefonunkról azt sem tudjuk, hogy mi miatt használt el mennyi adatforgalmat ill. akkumulátor-töltést.

Szó nélkül töltjük le hetente az újdonságot nem hozó frissítéseket, amikre csak azért van szükségünk, mert a programok/weboldalak igénylik, amik viszont csak azért igénylik, mert már mindenki frissített úgyis, és már ez az aktuális.

Úgy teszünk, mintha a szoftver ingyen volna, és ezért elvárásaink se lehetnének vele szemben, pedig még ha a bekerülési költségét tekintve ingyenes is, a használati költségét tekintve nem az, mert a pénzünkkel fizetünk a sávszélességért, az akkutöltésért, a megbízhatatlanság miatt szükséges mentésekért, az adatvesztés okozta kárért, az időnkkel az összes járulékos (azaz nem a célra irányuló) ráfordított kattintásért, a figyelmünkkel az arcunkba tolt összes spamért és reklámért. Jócskán van ára a szoftvernek (különben nem lehetne belőle megélni), viszont mégis úgy fogadjuk, mintha ajándékba kaptuk volna...

 

Összefoglalva

Az alkalmazói szoftverek terén tehát nem igazán beszélhetünk termékről, tehát iparról sem, és ennek megfelelően mérnökről is csak elég ritkán.

Túlnyomórészt a jóindulatra épülő ad-hoc fejlesztgetés és többé-kevésbé jóra törekvő, ámde kontrollálatlan háztáji munka zajlik, aminek pontosan annyi köze van az iparhoz, mint egy favelában épülő falaknak és házaknak az építészethez és az épületgépészethez.

Ennek pedig a legfőbb, a kontroll hiányán is túlmutató oka a norma hiánya: a túlnyomó többségnek nincs is igénye ennél jobbra.

Mivel bizonytalan alapra stabil dolgot építeni nem lehet, ez a trend így fog sajnos folytatódni is. Kiváltani ezt legfeljebb egy igényes hozzáállásra alapuló szoftver-kultúrával lehetne, viszont annak már induláskor kellene mindazt tudnia, amit a mostani instabil info-világ úgy-ahogy, de tud, ezt pedig egy lépésben lehetetlen megtenni.

Tehát a 'szoftvermérnök' és '-ipar' alá továbbra is odaértjük ezt a színvonalat is, a hagyományos, vagy most már mondhatjuk azt is, hogy a valódi mérnökség és ipar fogalmát is devalválva ezzel.

"Valahol egy fa keményen dolgozva állítja elő azt az oxigént, amit mi most erre elpazaroltunk. Ideje volna lassan megkeresni, és legalább megköszönni neki az erőfeszítést..."