Vajon tenyleg csak veletlen egybeeses, hogy az elmult 5 napban haromszor lattam rokat? Londonban?!

Es ekozben estenkent Fekete Istvan Vuk c. regenyet olvassa Greta Dianak…

Megint egy ekezetek nelkuli post.

Minap volt az egyik kolleganak interjuja, es meglepodott, hogy nem arra voltak kivancsiak, hogy mit tud, hanem hogy hogyan csinalja a dolgokat. Elgondolkozva a dolgon, valoszinuleg en is hasonlo dolgokat kerdeznek.

Miert? Mert egyre inkabb ugy latom, hogy programozokent, foleg a Java vilagban, nem tudhatsz mindent. Termeszetesen van egy alapszintu elvaras a nyelvet tekintve, de framework specifikus tudasba belemenni mar szerintem folosleges. A legtobb framework eleg hamar megtanulhato. Termeszetesen mindenhol vannak trukkok, amiket tudni kell, de azt nem varhatjuk el, hogy egy jelentkezo mindent tudjon elore, amit kell.

Ezzel szemben fontos az, hogy milyen a szemelyes motivaltsaga, es munkastilusa. En is ismerek jopar olyan programozot, akik gyorsan csinalnak mukodo kodot, aranylag alacsony hibaszinttel, de megis rossz veluk dolgozni, mert a kod, amit gyartanak, elter az “ipari sztenderd”-tol. Az is kifejezetten furcsa, ha egy programozo nem kepzi onmagat, nem olvas szakmai konyveket, blogokat. Meglepo, ha programozas kozben allandoan az egerhez nyulkal. Kifejezetten rossz, ha nem tud alapszinten banni az eszkozokkel, amik a programozason tulmutatnak: build tool (ant, maven, etc), IDE of choice (eclipse, netbeans, IntelliJ), verziokontroll, hogy csak nehany peldat mondjak.

Szoval, mit csinalnek en? Osszelonek egy gepet, tennek ra ide-t, verziokovetot, internetet, aztan megmondanam a vizsgazonak, hogy itt az url a verziokovetohoz, szedd ki ezt az alapvetoen hibas, kicsike programot valami ismeretlen nyelven, javitsd meg, es kommitold vissza. Van ra egy orad.

A lenyeg nyilvanvaloan nem az, hogy megjavitsa, hanem az, hogy lassam, hogy all hozza. Mit hasznal es hogyan. Ha nem tud valamit, akkor rakeres-e az interneten. A kod, amit ir, milyen minosegu, stilusban mennyire illeszkedik a programhoz, amit javitani kell. Ir-e kommentet, amikor becommitolja a kesz kodot.

Manapsag ezeket a tulajdonsagokat tartom fontosnak egy programozonal. Nem akarok olyan emberrel dolgozni, aki gyonyoru, agyonoptimalizalt kodot gyart, amit ket het mulva egy napig kell olvasnom, mire felfogom annyira, hogy atirjam benne ket fuggvenyhivas sorrendjet.

What will happen if we do the following in Java:

in package p1, we have a publicly visible class (VisibleClass1) with a publicly visible function (visibleMethod) which is declared to throw a checked exception (ProtectedException). ProtectedException is an inner class of VisibleClass1, with protected visibility.

in package p2 we have a class (Class2) which calls VisibleClass1.visibleMethod on an instance of VisibleClass1.

Possible solutions:

1. Compilation error in VisibleClass1, because visibleMethod’s visibility differs from the visibility of ProtectedException
2. Compilation error in Class2, because the thrown exception is not visible, so that the method can not be called from there
3.  It will allow you to import and catch ProtectedException in Class2, because of the visibility override rules in the compiler.
4. It will allow you to call visibleMethod, but you need to catch a visible superclass of ProtectedException (java.lang.Exception, for example)
5. You need to statically import VisibleClass1.ProtectedException, as if it would be an inner class, and then you can use it.

One of these is true..