saxus blogja

Németország, napelem: 40 GW beépített kapacitás, 2015-ben termeltek 38737 GWh-t.
Németország, szélkerék: 44,6 GW beépített kapacitás, 79210 GWh megtermelt áram.
Paks: 2 GW beépített kapacitás, 2015-ben termeltek 15834 GWh-t.

Gyakorlatilag nap esetén 20x, szél esetén 22,5x annyi beépített kapacitással termeltek meg nem egész 2,5x és 5x annyi áramot. Viszont nagy különbség, hogy Paks ezt folyamatosan képes, Németországban úgy esett 2%-ot a megtermelt energia 2016-ra, hogy a beépített kapacitás meg 6-7%-ot nőtt. Ráadásul a tengerpart miatt Németországban egy szélerőművel kb. 3x annyi áramot lehet megtermelni, mint nálunk a Kisalföldön, ami még mindig a legalkalmasabb terület itthon.)

Kétféle dokumentáció létezik: a hasznos és a nyilvánvaló. Hasznos az, ami rendelkezik valami plusz mondanivalóval és olyan információt ad át, ami egy szignatúrából nem feltétlen derül ki. Például, hogy egy metódus, ami kikotor valahonnan valamit, az exceptiont dob-e vagy null-t ad vissza. (Most attól tekintsünk el, hogy szerintem referencia típusnál is csak akkor kellene engedélyezni a null-t, ha azt explicit megmondjuk, picit hasonlóan a Nullable<T>/foo?-hez.)

Ezen infók jellemzően fenn vannak az MSDN-en, vagy akár a metainfók között, csak épp a VS nem jeleníti meg, ami nem segíti túlzottan a produktivitást. Szomorú.

Ilyen is ritkán van, amikor van egy négy szereplős történet (IETF, Microsoft, PHP, egy API-nak a tervezői) és kivételesen nem a PHP-t kell szidni. :)

Probléma: van egy API, ami gyakorlatilag egy RFC, URL encodeolva kell elposztolni nekik a kérésem, ami áll egy felhasználónévből, magából a kérésből és egy hashból, ami sha1(urlencode(request) + sha1(jelszó)) formában épül fel. Probléma az, hogy az az encodeolt URL-ben a %XX-nél engedélyezett a %xx is, ami ugye egészen más hasht eredményez. Ezt az ide vonatkozó RFC 1738 is világosan leírja:

...postgresql scriptet láttam.

Történt az, hogy egy kis pg_hba.conf heggesztés után balfasz módon megpróbáltam a saját useremmel reloadolni a PostgreSQL-t:

[saxus@xxx-db-pgsql ~]$ /etc/init.d/postgresql-9.3 reload
[saxus@xxx-db-pgsql ~]$

...csak épp kurva jó lenne tudni, hogy ki fogja ténylegesen kihozni a csomagot.

Nem értem, miért olyan nehéz ezt feltüntetni weben, hogy ki hol kivel van szerződésben. Vagy még inkább: létrehozni egy egységes, EU-s tracking rendszert, amibe köteles lenne az összes EU-s posta és futárcég csatlakozni. Eskü, nem sajnálnám rá az adót.

Kellett volna egy kis egyszerű nyilvántartó program, már-már olyan, amire az ember fog egy Excel Onlinet/Google Docst. Viszont jó lenne, ha kissé auditálhatóbb lenne, hogy ki mit mókolt. Jelen esetben bőven megtette, ha csak beszúrjuk az új rekordot és dátum alapján vesszük mindig a legutolsót. Esetleg fel lehet tartani egy index táblát, ha kicsit optimalizálni akarunk a sebességre, de ez legyen már a jövő zenéje. Szóval olyan jó két-három órás feladat összerakni az egészet pgsql+WPF alapon.

Egyetlen bökkenő: desktop és futnia kellene több helyről. Auch.

Ez de szép. Ugye a mono kapcsán volt itt a sírás-rívás, hogy a Microsoft és (képzelje ide mindenki a kedvenc mantráját), és majd jön és jól megrak, használjon mindenki inkább Java-t, mert nyílt és szép meg jó és stb.

Aztán most a Google lett végigszopatva és kénytelen átállni OpenJDK-ra (meg valószínűleg fizetni egy jó adag pénzt), mert a Java API márpedig az Oracle szellemi tulajdona és irgum-burgum.

Egyébként egyfelől jót fog tenni az OpenJDK az Androidnak, hogy picit előre rugdossa a Javat, viszont felvet néhány érdekes kérdést:

- Hogy lehet az API miatt perelhető valaki, ha az nyílt?
- Most akkor nyílt-e a Java vagy sem?
- Van-e lehetőség egyéni Java implementációt készíteni anélkül, hogy az Oracle rommá perelné az embert? (Láthatóan nincs.)

Tegnap egyik kolléga panaszkodott, hogy van egy kisebb issue az egyik régi legacy rendszerünkkel és picit meg kellene patkolni. Sebaj, essünk neki.

Lett is egy query, ami megmondta, hogy mit kellene kipucolni a DB-ből bizonyos esetek fennállása esetén, ami nagyjából így nézett ki:

SELECT id FROM Tabla LEFT JOIN masik tabla ON tralala WHERE blablabla

De hívjuk csak így, hogy

SELECT id FROM Tabla WHERE blabla

, mert a példához elegendő.

Mivel nem sok adatról van szó, elvileg nem lehet abból gond, ha ezt az ember berakja egy sima DELETE querybe, mondjuk így:

...decemberben szól, hogy áprilisban már volt referencia implementáció...

Mivel szerettem volna ezt részletesebben kifejteni már régebben, ezért gondoltam itt válaszolok erre a hozzászólásra.

Szóval az van, hogy ne szépítsünk: a Skype a Windows Phone szégyenfoltja. Nem lehet rá azt mondani, hogy "hát, ez nem az igazi", meg hogy "van jobb is", ki kell mondani, ebben a formában egy vállalhatatlan határ fos.

Legfőbb probléma:
- Lassú. Istentelenül lassú. 6-8 másodperc, mire elindul, a szintén nem feltétlen sebességbajnok Facebook Messenger is megvan 1,5..3 mp alatt. És ez még csak az indulás.
- Baromira nem reszponzív. Komolyan mondom, egy ótvar alsó kategóriás Android hozzá képest csoda. Ha valami úgy általában rendben van a WP-n az a reszponzivitás, na itt szörnyű. Benn vagyok egy beszélgetésben nyomkodom a jobb felső sarokban lévő menüt vagy a vissza gombot és semmi, várok, várok, még mindig várok, mire végre méltóztatik csinálni valamit. Olyan, mintha az STAThread-en csinálna mindent, csak épp néha még nekiáll kimatekolni az élet értelmét.
- Kiszámíthatatlan. Néha nem teljesen megjósolható módon csak az asztali vagy csak a telefonon cseng a hívás.

Oh wait.

http://www.europarl.europa.eu/sides/getDoc.do?type=REPORT&reference=A8-…

/me ránéz az órára, látom 2015, annak is a vége fele közeledik, majd sóhajt egyet.

Komolyan, mibe fájt volna a cikk ismételt előcibálása helyett *egyszer* megírni azt az update queryt, ami előre/hátra mozgatja az összes user beállítását?

tl;dr:

1) Hogy a francban fért el egy kb. 8-9mm-es gömbnyi mocsok az egérgörgő körül?
2) bakker, ilyen is lehet egy egérgörgő? :D

Viszont szívesen elbeszélgetnék a Skype tervezőivel, hogy ilyenkor vajon mi járhatott a fejükben, mikor ezt kitalálták:

Tudom, old meg minden, de nagyjából jól összefoglalja, hogy tulajdonképp mekkora önszopatás az egész Linuxos ökoszisztéma egy webapp esetén:

http://eev.ee/blog/2015/09/17/the-sad-state-of-web-app-deployment/

(Megjegyzés: fingom nincs, hogy ASP.NET esetén mi a helyzet, nem is érdekel jelenleg.)

Éjjel végre migráltuk az adatbázisokat egy új szerverre és a DB-k kaptak SSD-t.

http://imgur.com/a/c7IHA

Megoldás: törölni a .sou fájlt.

Aki meg VCS-be rak .sou fájlt, azt meg péklapáttal megnevelni.

Jegyzet magamnak.

WITH summary AS (
    SELECT p.id, 
           p.customer, 
           p.total, 
           ROW_NUMBER() OVER(PARTITION BY p.customer 
                                 ORDER BY p.total DESC) AS rk
      FROM PURCHASES p)
SELECT s.*
  FROM summary s
 WHERE s.rk = 1

(Innen: http://stackoverflow.com/a/3800572 )

Ja nem: http://fortune.com/2015/04/28/exclusive-gaming-startup-ouya-needs-to-fi…

Egy blogposztban említette eszes, hogy nem érti, hogy mégis mire jó "professzionális" felhasználásra az Excel/*O Calc és az Access/*O Base. (Vagy tetszőleges táblázatkezelő, irodai szoftverben található adatbázis-kezelő.)

Ma volt egy meetingmegbeszélés a saleseseknek, ahol fél füllel elkaptam, hogy az egyik régi oldalunknál tök jó lenne egy-két statisztika, amit egy-két másik oldalunk már tud, csak még a régi átalakítása az újra folyamatban van. Mondom, sebaj, végül is 3 db insert-tel elő lehet generálni a szükséges adatokat, hogy abból statisztikát lehessen faragni. Ez a három tábla elkészítésével és a deploymenttel együtt tartott talán 15 percig. A MySQL-ben* kellett még egy plusz user a saleseseknek, akik elérték a 3 napló táblát meg még kettőt, SELECT-re, ami szükséges volt ahhoz, hogy lehessen benne értelmes lekérdezéseket készíteni. Még kb. 10 perc.

Korábbi blogposztomnál merült fel az a kérdés, hogy vajon mit szólhat egy oldal üzemeltetője ahhoz, hogy az egyébként kézzel végzet tevékenységem megpróbálom számomra (időben) hatékonyabbá tenni és automatizálni az adatok letöltését, összegyűjtését, ugyanis kézzel meglehetősen sok macera 200 különféle tétel között végigböngészni, hogy melyik árusnál van olcsóbban és ezt összelogisztikázni, hogy a lehető legkevesebb rendelésből (mert ha nem BP-i személyes átvétel, hanem teszem azt, Németország, akkor a postaköltség is jelentős tétel lesz). Ezt egy adatbázisban egészen jól meg lehet csinálni. Meg elvégre is, erre van a számítógép.

Tegnap esti task: adott egy özönvíz előtt készült oldal, még HTML4-es időkből, tablefull design, CSS mutatóban, ahogy kell. Miután API az nincs (ill. van, csak nem arra, amire nekem kellene), így maradt az, hogy parseolom az adatokat valahogy.

Na de a valahogy része már nem olyan egyszerű. XML és (nem retardáltak által írt) XHTML esetén ezzel nem lenne gond, megnyitom a kedvenc és/vagy feladatnak megfelelő XML olvasóval s TADA.WAV.

Miután nem igazán van a .NET-ben alapból se HTML se SGML parser mindenképp gányolás lett a vége, ami jelen esetben a System.Windows.Forms.WebBrowser használata. (Természetesen csak gányolással működik egyszerűen). Segítek: leánykori neve Internet Explorer, legalábbis abból a megjelenítésért felelős komponens. Miért nem kerestem rá SGML parsert? Mert messziről látszott, hogy az oldal semmiféle validátoron nem menne át, ellenben a böngészők megeszik

https://www.youtube.com/watch?v=tW-wSti5Y6M

No comment.

Ebben a topicban az a szép, hogy előjött a csomagkezeléssel kapcsolatos összes nyűg már megint. (Legalábbis, ameddig olvastam, mert a felénél benyomtam egy tl;dr-t, semmi újat nem mondott a topic). Azaz, jajdejó, mert aptget install fapfap, és kezeli a függőségét és ez mennyire jó, persze időnként nem, mert juj hát milyen már, mikor eltérő verziók kellenek programoknak meg a többi.

Vicc az, hogy a mostani docker hypeal pont oda jutunk, amire a csomagkezelő elvileg megoldást akarna nyújtani (nem végzik el jól - gyengébbek kedvéért: a csomagkezelők): majd minden cucc hozza magával a függőségét, és ha a konténerben elavult függőség van, akkor IJB. (Most a docker egyéb előnyeitől, képességeitől tekintsünk el.)

https://github.com/dotnet/roslyn/issues/227