ÉnKép - takacsot

Gyimóthy Gábor: Nyelvlecke

Egyik olaszóra során,
Ím a kérdés felmerült:
Hogy milyen nyelv ez a magyar,
Európába hogy került?

Elmeséltem, ahogy tudtam,
Mire képes a magyar.
Elmondtam, hogy sok, sok rag van,
S hogy némelyik mit takar,

És a szókincsben mi rejlik,
A rengeteg árnyalat,
Példaként vegyük csak itt:
Ember, állat hogy halad?

Elmondtam, hogy mikor járunk,
Mikor mondom, hogy megyek.
Részeg, hogy dülöngél nálunk,
S milyen, ha csak lépdelek.

Miért mondom, hogy botorkál
Gyalogol, vagy kódorog,
S a sétáló szerelmes pár,
Miért éppen andalog?

A vaddisznó, hogy ha rohan,
Nem üget, de csörtet – és
Bár alakra majdnem olyan
Miért más a törtetés?

Mondtam volna még azt is hát,
Aki fut, miért nem lohol?
Miért nem vág, ki mezőn átvág,
De tán vágtat valahol.

Aki tipeg, miért nem libeg,
S ez épp úgy nem lebegés, –
Minthogy nem csak sánta biceg,
S hebegés nem rebegés!

Mit tesz a ló, ha poroszkál,
Vagy pedig, ha vágtázik?
És a kuvasz, ha somfordál,
Avagy akár bóklászik.

Lábát szedi, aki kitér,
A riadt őz elszökell.
Nem ront be az, aki betér. . .
Más nyelven, hogy mondjam el?

Jó lett volna szemléltetni,
Botladozó, mint halad,
Avagy milyen őgyelegni?
Egy szó – egy kép – egy zamat!

Aki „slattyog”, miért nem „lófrál”?
Száguldó hová szalad?
Ki vánszorog, miért nem kószál?
S aki kullog, hol marad?

Bandukoló miért nem baktat?
És ha motyog, mit kotyog,
Aki koslat, avagy kaptat,
Avagy császkál és totyog?

Nem csak árnyék, aki suhan,
S nem csak a jármű robog,
Nem csak az áradat rohan,
S nem csak a kocsi kocog.

Aki cselleng, nem csatangol,
Ki „beslisszol” elinal,
Nem „battyog” az, ki bitangol,
Ha mégis: a mese csal!

Hogy a kutya lopakodik,
Sompolyog, majd meglapul,
S ha ráförmedsz, elkotródik.
Hogy mondjam ezt olaszul?

Másik, erre settenkedik,
Sündörög, majd elterül.
Ráripakodsz, elódalog,
Hogy mondjam ezt németül?

Egy csavargó itt kóborol,
Lézeng, ődöng, csavarog,
Lődörög, majd elvándorol,
S többé már nem zavarog.

Ám egy másik itt tekereg,
– Elárulja kósza nesz –
Itt kóvályog, itt ténfereg. . .
Franciául, hogy van ez?

S hogy a tömeg miért özönlik,
Mikor tódul, vagy vonul,
Vagy hömpölyög, s még sem ömlik,
Hogy mondjam ezt angolul?

Aki surran, miért nem oson,
Vagy miért nem lépeget?
Mindezt csak magyarul tudom,
S tán csak magyarul lehet. . .!

Firenze 1984. X. 12.

Original

All IT systems at some point in their lifecycle need to consider non-functional requirements and their testing.

...

Based on your own project characteristics, I would recommend the topics are converted into SMART (Specific, Measurable, Attainable, Realisable, Timeboxed / Traceable) requirements with the detail and rigour appropriate to your project.

Original

• Storytelling, problem solving and gossip. The ScrumMaster must be ready to prompt the team members to answer the right questions and to stay on track.

• Reporting to the ScrumMaster. The purpose of the meeting is for the team members to talk to each other. The ScrumMaster keeps his role to a minimum and keeps the focus of the discussion in to the group. If the team falls back to reporting, conversations become bilateral between ScrumMaster and team member, and other team members risk tuning out. The ScrumMaster’s taking notes is a symptom of this behavior. A variety of strategies, such as rotating the facilitator, passing a “microphone” or having the last person to come start the meeting can be used to mitigate this effect.

• Accounting for time rather than results and goals. Team Members should focus on goals and not just on how they plan to pass their time.

• Invisible (electronic) task boards make it much harder for people to identify and focus on their goal for the day or identify when a team member has not fulfilled his commitment. Ask your team how to solve this problem.

• Other stakeholders attending the Daily Scrum. This is not forbidden, but it is an opportunity for them to give to attempt to give unsolicited advice and instructions. The ScrumMaster should pay close attention to the dynamics and prevent inappropriate interference.

• Late Arrivals and Unexcused Absences. Arriving late disrupts the Daily Scrum, threatens the time box and increases the cost of the meeting. Information transfer doesn’t happen or has to be repeated. These can be a sign of resistance or rebellion or other deeper problems which need to be addressed. The shared commitment is called into question. If the delinquent team members also refuse to pay their fines, this is a further sign that work on the team identity, commitment, or the value of the Daily Scrum is necessary. The Retrospective is the place to discuss the value of the Daily Scrum and the teams commitment to doing it.

• Not raising impediments. In some contexts (e.g. if trust is lacking or in cultures where maintaining face is important), it may be difficult to raise issues in a meeting. People sometimes forget to mention things in the Daily Scrum. In either case a visible impediments list on the task board where team members are expected to post impediments directly, may be helpful to raise and track impediments.

• Not handling impediments. This might be a weakness in the ScrumMaster (e.g. conflicting priorities, overwork, or personal preference) or it might be a visibility problem. In either case, it can be demotivating -- why report problems if no one will do anything about them? Making impediments visible on the task board can help with this problem.

• Not helping each other. “I’m a developer! You can’t expect me to help a tester.” Getting the team to work together as team is a major goal of the ScrumMaster during the first few months of doing Scrum.

• Low Energy - People come, they go through the motions and they leave. And no one really cares. If this is more than just a Monday morning phenomena, then it is a problem to be identified in the Retrospective. Personally, I would be inclined to call a retrospective immediately if this problem persisted for more than a few days.

Original

Igazén igaz megállapítás a Planning pókerről.

Az én első élményem a CSM tréningen volt és igen hatásosan sikerült látványossá tenni az eredményt. Mivel ott 5 asztalnyi ember  egymástól függetlenükl estiálta ugyan azt a feladatot. Az eredményülkapot SP-k igen extrémen eltértek. De mikor egyetlen feladatot taskokra bontottuk és órákban megbecsültük az eredményt pedig kivetítettük a teljes SP-re kiderült, hogy kb ugyan azon a területen mozgott mindenki munkabecslése. És gyakorlatilag minden percek alatt olyan projekten, ami lefejlesztése heteket, hónapokat venne igénybe.

Original

Oracle: Ki van bejelntkezve és milyen query-t futtat. Hasznos, ha memóriaszivágás esetén.

select status, username,  schemaname, osuser, machine, terminal, program,
s.module, logon_time, event, seconds_in_wait, state, s.sql_hash_value,
s.prev_hash_value,  q1.sql_text, q2.sql_text perv_sql_text
from v$session s, v$sqlarea q1, v$sqlarea q2
where s.sql_hash_value=q1.hash_value(+)
and s.prev_hash_value=q2.hash_value(+)
and schemaname<>'SYS'
order by status, username
 

Csak egy kis gyüjtemény a rendszeresség kedvéért

Original

 Átfutottam a egy a Ruby-rólmint nyelvről szóló könyvet. Mondjuk az átfutás azt jelenti, hogy nem nem csináltam meg minden feladatot,ami a könyvben le volt írva.

A könyv jó is meg borzalmas is. Jó, mert Ruby bevezető-nek is jó. Azaz a legalapabb dolgoktól kezdve elég bonyolult dolgokig minden van benne. Jó, mert nagyon jó, életszagú példákat tartalmaz. Borzalmas, mert nem rendszerezett. Az biztos, hogy ezt akönyvet nem fogom tudni referenciaként használni, mert kapcsolódó információk elszórva helyzkednek el a könyvben. A nyers referenia nyelvi ismeretek keverednek a példaprogram ismertetésével. Borzalmas, mert nagyn alapoz a letöltött példaprogramokra (fizikai könyvhöz valószínüleg egy CD is jár). Gyakorlatilag azok nélkül nemlehet kipróbálni a könyvbeni példák jelentős részét, mert gyakran nagyon fontos részek csak a példaprogramokban van meg a könyv példája meg "csak" használja azokat.

Eredmény: hmmm. Egynek jó.

Review 1

Könyv honlap

Hogyan került a szemem elé? Egy youtubos előadáson az előadó említette, hogy a modern kor  Smalltalkja. Ez felkeltette a kíváncsiságomat. Gyorsan összeszedtem pár Ruby könyvet és elkezdtem olvasni. De maga a nyelv nem olyan érdekes. De van egy webes keretrendszere, a Rails, amiről csupa jót hallottam. Szóval inkább abba vetettem bele magam. Majd láttam, hogy ott a JRuby is. Mivel Java területen otthon érzem magam, jó választásnak tűnt.

Majd nekiestem ennek a könyvnek mondván ebben benne van minden, ami nekem kell. De kicsit más lett. 

1. A Ruby nyelv azért nem triviális, de hát istenem.
2. A könyv 1.X-es Rails-vel dolgozik, nekem meg 2.2-es railst szedett le a gems. Sajnos nem kompatibilis. Pontosabban szólva a generált filok nem pont ugyanazok.
3. Nem az én konvencióimat követi. Ugye a rails a konvenciókat helyezi a konfiguráció elé. Nagyon jóllátszik, hogy pl a classok nevei és az adatbázis táblák nevei között. De a konvenciók nem minden esetben tetszenek. Pl az osztály neve legyen Alma. A tábla neve pedig almak. Azaz a táblanevek többesszámúak. Ez pedig nem egyezik a relációs model elveivel. Ugyanis az adatbázistáblák nem gyüjtők, hanem metadata és adathalmaz együttesen. Relációs modell szerint ennek is alma-nak kellene lennie.

A könyvben egyébként kevés dolog szólt a rails-ről jruby környezetben. A rails-es részek igazából a jdbc beállításokon kívül nem szóltak Java-ról. Ahol keveredett a Java-val ott nem a rails volt lényeg, hanem a jruby és java interakció.

Igazából a rails nem kompatibilitás miatt nem csináltam meg a könyv példáit. De elolvastam lelkiismeretesen. Most már tudom, hogy mit keressek ebben. Ami kiderült, hogy kell egy alaposabb ruby ismeret és egy rails könyv a 2.X-es verzióról.

 javaworld

Könyv forrásai

Kivonat

Tartalom

Bűnbankok

 Azt hiszem mondhatjukazt, hogy manapság 3 igazán elterjedt böngésző van: Internet Explorer, Firefox, Google Chrome. 

Az IE igazából csak a windows miatt elterjedt, bár a legújjabb vezriói már használhatóak, de egy vérbeli internetesnet gyenge támogatást adnak. 

Firefox: Valólyában nem nagy szám magában, de a pluginekkel együtt fantasztikus dolgokat lehet belőle kihozni.

Chrome: Hát! Az elgondolás jó, de még nem elég fejlett. Egyszerűen egy csomó olyan dolog hiányzik belőle, amit mér megszoktam és napi szinten szeretném használni. A mostani csalódásom például azm higy van egy csini netbookom,aminek közismeretn kicsi a képrenyője. De sebaj, mert a legtöbb böngészőt F11-vel fullscreenbe lehet tenni. Chromot nem lehet. A mouse gestures feature pedig csak azoknak nem hiányzik, aki még soha sem használta. olyan, mint a görgős egér. Amig nem volt akezedben addig nem hiányzott, de ha egyszer volt a kezedben, akkor nem tudsz nélküle dolgozni. másik, hogy konkrétan tököm kivan attól, hogy vagyok oldal közepén klikk a linkre, majd egy laza back-vel mennék vissza oda, ahol voltam, DE nem az oldal közepére kerülök, hanem a az oldal tetejére. Idegtépő!

Opera: Még most is sok tekintetben forradalmi böngésző. Rengeteg dolgot évekkel a többi böngésző előtt vezetett be. És a  tapasztalatom szerint még mind a mai napig a leggyorsabb böngésző. Mese nincs, még mindig ez a kedvenc. Fejlesztéshez A firefox, mert a pluginjjei verhetettlenek, de a mindennapokban bizony az Opera az én emberem.

 Olyan dolgokat ír le, amiket én is látok. Nem egyedülálló dolog. De a tanulság az, hogy agile dolgok akkor erősek, ha van támogatottságuk. Ha nincs támogatottság, akkor úgy is mindegy, akkor amúgy se menne semmi más sem.

Original

 Original 

 Nincs mit hozzá fűzni. Olyan dolog ez, amit már 70-es években felmértek és megállapítottak. de valami miatt nem vesznek figyelembe.

Original

Nem is kell t0bb. Nekem elég.

Original 

 But the best part of the whole discussion of story points comes when I talk about release planning using a Product Backlog estimated in story points (or at least that portion of the Product Backlog intended for the next release of software, which I typically call the “Release Backlog”). That when I spring this one on them:

If your estimates are consistently incorrect, you are perfectly predictable.

That’s when you can really hear the churning going on in the heads of my students.

“Perfectly predictable? How can incorrect estimates be predictable?”

Here’s where I usually wait a few seconds to see if I’ve hurt anybody.

Then I explain – first, that estimates are, by definition, wrong. PBIs (Product Backlog items) estimated at 2 story points may take 80 hours or 180 hours. I won’t know until they’re completed. However, if I get good at recognizing 2-story point items (which will happen if I do backlog grooming properly), almost all of them will fall within an upper and lower limit (don’t ask for the statistical proof, please). In other words, after I do enough 2-story point PBIs, a large majority of them will be more than 80 hours, but less than 180 hours. In fact, the more I do, the more likely that range will get smaller (maybe 100-160 hours) and possibly even smaller.

This is, in fact, one of the most powerful aspects of story points – rather than spending lots of time getting unnecessary precision, we can accomplish the same thing by estimating lots of PBIs in terms of story points and spending a lot less time doing it.

Original

  Original

Mottó: Egy kurva is megtalálja élete értelmét.

Érdekes, erotikus könyv. hagyon kellemes hangú előadóval. Pont megfelelt arra, hogy egyéb agyat nem, de kezet lefoglaló dolgok mellett meghallgassam. Kellemes könyv és az ember párjával hallgatva könnyen szexrehangoló is lehet.

1200 MÉTER FALLOSZ

 Varázslatos történetek. Gaiman-től elvárt stílus. Minden történet más és más. Varázslatos.

Részlet

Vélemény

Kettős érzületem van a könyvvel kapcsolatban. Elsőre teljesen jó, hiszen elképesztően jó gondolatokat gyüjt össze. Másodsorban viszont kiábrándultam, mivel ezek korábbi blog bejegyzések, amik többségét én már korábban olvastam. Szóval szívás. De egyébiránt csak javasolni tudom mindenkinek

Chapters include:

• The A to Z of Programmer Predilections
• The Hazards of Being Quality Guy
• A Dozen Ways to Sustain Irrational Technology Decisions
• My Kingdom for a Door
• Interview with the Sociopath
• The Art of Flame War
• Testers: Are They Vegetable or Mineral?
• Corporate Pimps: Dealing With Technical Recruiters
• Developers are from Mars, Programmers are from Venus
• To The Management
• Great Mistakes in Technical Leadership
• The Architecture Group
• The Mismeasure of Man
• Meeting Driven Development
• Extreme Deprogramming
• New Methodologies or New Age Methodologies?
• Rhetorical AntiPatterns in XP
• The Deflowering of a Pair Programming Virgin
• XP and ESP: The Truth is Out There!
• Thought Leaders and Thought Followers
• Dude, Where’s my Spacecraft?
• User is a Four Letter Word
• The Folly of Emergent Design
• The Top Ten Elements of Good Software Design
• Oral Documentation: Not Worth the Paper it’s Written On
• FUDD: Fear, Uncertainty, Doubt and Design Documentation
• Get Your Filthy Tags Out of My Javadoc, Eugene
• Naming Classes: Do it Once and Do it Right
• In Praise of Code Reviews
• Web Accessibility for the Apathetic
• SWT: So What?
• Debugging 101
• Spare a Thought for the Next Guy
• Six Legacy Code AntiPatterns
• The Skeptical Software Development Manifesto
• Basic Critical Thinking for Software Developers
• Anecdotal Evidence and Other Fairy Tales
• Function Points: Numerology for Software Developers
• Programming and the Scientific Method
• From Tulip Mania to Dot Com Mania
• The Crooked Timber of Software Development
• From James Dean to J2EE: The Genesis of Cool
• IEEE Software Endorses Plagiarism
• Early Adopters or Trend Surfers?
• Reuse is Dead. Long Live Reuse
• All Aboard the Gravy Train

egy link a jok közül

• Plan for Ajax from the start.
• Implement Ajax at the end.

Original

Sokkal inkább menedzsmentnek íródot, mint programozónak. kb max 10 sornyi példaprogram van a könyvben. Amiben jó lehet az, hogy a Ruby-ra állásra ad stratégiákat.

Honlap

 1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream.

2. Work required to fix bugs shouldn't count towards the teams overall story point velocity. You don't what to show an increase in velocity for buggy code.

3. Bugs should be treated just like tasks are treated on the Sprint Backlog and should be tracked on the Burndown. Bugs take time to fix and so you have to account for the hours.

4. Teams should not confuse Sprint capacity plannning with longer term Story point planning i.e. bugs should not be estimated in Story points.

Kicsit megkéstem a hírrel, de nem gond.

Február 23-24-én Bécsben részt vettem egy Certified ScrumMaster tréningen. Előadó Mitch Lacey. Eredmény egy certificate, hatalmas kimerültség és hatalmas élmény.

De honnan is jött az ötlet? Alapvetően már elkezdtem a cégen belül használni olyan technikákat, amik agilisek, sőt majdhogynem Scrum-os. A tapasztalatom és az eredmények jók voltak. A csapat értette az elveit és jónak találták a technikák jelentős részét. Amivel igazából gond akadt az a taskokra bontás. Mondjuk ezzel most is bajok vannak. De azért hiányzott valami.

Én Scrum-ot személyesen mástól csak egyszer láttam a SAP-os éveim alatt. Látni és párszor beszélni egy olyan emberrel aki akkor is még csak tanulta és messze nem profi más. Szükségem volt olyanra, aki tapasztalt öreg róka.

Kerestem magyar előadókat és találtam is, de olyan lassan reagált, hogy inkább bejelentkeztünk a Bécsi tréningre. Sajnos Scrumalinace-tól ott van a legközelebbi tréning, de abból is csak ez volt angolul. A többi természetesen németül megy. Szóval beindítottam a folyamatot. Szerencsére a Cég fizette, bár kit érdekel, és akár magam is fizettem volna. Végül 3 másik munka társammal mentem el. (Mondjuk ebből volt is konfliktus, mert másokat is érdekelt volna, de hát több,mint egy hónappal a tréning előtt kezdtem szervezni és mivel főleg magamnak nem tudom azt sajnálni, aki nem szólt.)

Autóval ki Bécsbe. Meriott hotelben elszállás és mondhatjuk, hogy két napon át nem is láttam mást. Mondjuk Bécsben már többször voltam és nem érdekelt, de arra nem számítottam, hogy az agyamat ilyen mértékben ki foglya szívni.

A társaság jó volt. Szerencsére négyen nem egymás közelébe találtunk helyet így volt lehetőség keveredni a lokál emberekkel. Jó és érdekes társaság alapult ki. A közönség 3 csoportra oszlott. Akiknek volt kérdésük és problémájuk és mélyíteni szerették volna az ismereteket. Ebbe tudom magamat is besorolni. Második volt a szkeptikus. Szerencsére ebből kevés. Majd a kuka, akinek szavát nem lehetett fogni.

Az előadó már ismerős volt korábbról. Már láttam Youtube-os előadását arról hogyan bukott meg egy Scrumos fejlesztés. Nagyon érdekes és tanulságos. Mindenkinek csak javasolni tudom. Kiváló, érdekes és képzett előadó. Többször volt olyan érzésem, hogy egy Standup comedy szerű show-t ad elő. Magára az előadásra jellemző volt, hogy igyekezett az igényeinket kielégíteni. Már az elején összegyűjtötte a kérdéseinket és az előadást olyan irányba terelte, illetve olyan részeket emelt ki, ami ezekre a kérdésekre választ adott. Szünetekben nagyon közvetlen volt és jól el lehetett vele beszélgetni.

Maga a tréning anyag nem nagy szám. Nem a tréning anyag hibája. az interneten már annyi Scrum-os anyagot találtam és egész könyveket olvastam erről, hogy maga tréning nem a lexikális ismeretekben fejlesztett engem. Most már értem azokat a véleményeket, amik szerint a SCM tréning nem ér fabatkát sem. Igen a tréning nem ad többet ha az ember már ismeri és tapasztalata van. De EZ a tréning bizony több volt. Ahogy Mitch elmesélte saját tapasztalatait (nem publikusokat is, ekkor lekapcsolta a videó felvevőt is) az rengeteget jelentett. A saját konkrét problémáinkra adott tanácsok hasznosak, konzisztensek. De azt hiszen az világos, hogy nem Scrum alapjai miatt mentem oda.

Ami még fontos, hogy ezen az előadás során olyan dolgok kaptak nagyobb fókuszt, amire én magam nem fektettem hangsúlyt. Például a Scrum szerep körök pontos jellege és azok keveredése kapcsán. Ezt eddig fél vállról elintéztem, de nem szabad. komoly problémák forrása lehet.

Vannak jegyzeteim amiket igyekszem elektronikus formában is átírni. Elég adhoc jellegűek, de arra jók, hogy magamnak meg legyen mik a fontos és kiemelt tapasztalataim. Akkor pedig majd ide is fel fog kerülni.

Original