Excel LÁTVÁNYT.MUTAT

Lehet, hogy a korral jár, de már mindent használok, ami a munkámat könnyíti. Mostanában az Excel ez a nagy felfedezés, amiben számokon alapuló dolgokat elég jól lehet modellezni… Ez a remek kis termék ötletes funkcióival többször is meglepett, és persze az Office szoftvercsomag többi tagjához hasonlóan még többször idegesített fel (pl. valaki megmondhatná, hogy 2010-ben azonos nevű de más helyen lévő xls-t miért nem lehet megnyitni, meg miért nem tud az excel 2 vagy tetszőleges számú ablakban futni, vagy a feltételes formázás miért nem működik több munkalapon is, stb…). De ez a Microsofttól már megszokott, csinálnak valami jót (lásd Visio) és aztán a végén megfejelik olyan apró kis idegesítő bakikkal, amit ilyen szarul csak az MS berkein bellül lehet megoldani (pl. a visio layerek kezelése ékes példa erre…). Mondjuk lehet ez a védjegyük, de amíg nincs jobb, kénytelenek vagyunk ezzel élni.

Visszatérve az Excelre a legidegesítőbb dolog amit csak kitalálhattak, az a képletek lefordítása volt. Ha végre nagynehezen az ember megtalálja azt amit keresett, akkor szembesül csak azzal, hogy az órákig tartó keresgélés eredménye mitsem ér, hiszen a magyar excelbe minden magyar…

Talán maguk a magyar Excel készítői is szembesültek ezzel, ezért is került bele egy táblázat, ami minden képletet eredeti nyelven is tartalmaz 🙂

c:\Program Files\Microsoft Office\Office12\1038\FUNCS.XLS

Ha esetleg valaki nem 12 office-t használ akkor neki az a könyvtár más…

Gwt memory leak

Ezer éve nem volt módom (és időm) írni, de most sikerült, megtaláltam, és megengedek magamnak ekkora pihenőt. Jó ideje egy GWT alapú alkalmazás készülget, és eddig szinte minden „simán” ment a fejlesztés során, volt néhány kisebb trükk, pár gwt-s osztályt át kellett írni, de összességében szerintem a GWT keretrendszer jól teljesített, sőt felül is múlta az elvárásaimat.
Egészen tegnapig, amikor is azt jelezték, hogy az alkalmazás sok memóriát fogyaszt. Ilyenkor az ember hajlamos azt mondani, hogy persze, hiszen nagy alkalmazás, de a C++-hoz szokott énem rögtön kétségbe esett, ez bizony memory leak. Gyors mérések után a tünetek egyértelműek voltak. Az alkalmazás leak-el, menüpontonként pár megát. Az látszott, hogy nem a javascript memóriahasználata nő (google chrome kiírja), hanem a böngésző memória használata. Ekkor kezdtem gyanakodni, hogy ezt pedig mi rontottuk el, és a végén igazolódott is ez az állítás. A hibát csak a tanúsága miatt megosztom mindenkivel.

Az eredeti kód:


private void setLoadingVisible(boolean pVisible) {
if (pVisible) {
waitingPopup=new APopupWaiting(msgs.main_waitingmessage(), Window.getClientWidth(),Window.getClientHeight());
waitingPopup.center();
}
if (!pVisible && waitingPopup.isVisible()) {
waitingPopup.hide();
}

Ez a szolgáltatás arra szolgál, hogy ha tölteni kell, akkor kirak egy töltés dialógust. Első látásra minden rendben van, létrehoz egy újat, megjeleníti, vagy elrejti a megadott paraméter alapján. Az implementáció hibás, az már érdekesebb kérdés miért. Normál esetben maximum egy nem optimális implementáció lenne, hiszen miért hozunk mindig létre valamit, ami már egyszer létre lett hozva, ráadásul sohasem változik. Sokkal nagyobb probléma, hogy ez javascriptben fut, és a GWT a változót (és a hozzá javascript által generált HTML dom-ot) csak akkor szabadítja fel, ha már nincs rá referencia. Ellenben a PopupDialogra igen is lesz referencia, és nem a DOM-on keresztül, hanem azon eseménykezelők miatt, amikre működéséből fakadóan feliratkozott. Tehát az objektum lóg a levegőben, és fogyasztja a memóriát.

Egy lehetséges megoldás:


private void setLoadingVisible(boolean pVisible) {
if (pVisible) {
if (waitingPopup==null) {
waitingPopup=new APopupWaiting(msgs.main_waitingmessage(),
Window.getClientWidth(),Window.getClientHeight());
waitingPopup.center();
} else {
waitingPopup.center();
}
}
if (!pVisible && waitingPopup!=null) {
waitingPopup.hide();
}
}

Végezetül egy kis olvasmány (de az ellen nem véd ;):
http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks

XFCE Ubuntu alatt

XFCE telepítése:
sudo aptitude update && sudo aptitude install xubuntu-desktop

Az alapértelmezett session managert az alábbi utasítással állíthatjuk be:
sudo update-alternatives --config x-window-manager

Windows XP optimalizáció (zenéhez) #2

A Windows XP a végtelenségig optimalizálható, ezt mi sem mutatja jobban, min a sok több milliószoros sebességnövekedést igérő cikk, leírás, és szoftver. Persze a hardvernek, és a Windows XP-nek is vannak korlátai, de a fölösleges doglok kikapcsolgatásával el lehet érni, hogy inkább a hardver korlátait érezzük mint a Windows korlátait.
Tehát a további optimalizációk:

http://www.connectedinternet.co.uk/2007/02/06/the-complete-guide-to-optimising-windows-xp/

És egy elég részletes, de nem túl terjengős leírás a windows szolgáltatásokról:
http://beemerworld.com/tips/servicesxp.htm

Windows DPC

Amikor az ember időkritikus (valósidejű) dolgokra használja a számítógépét, szeretne biztosra menni. Ennek elengedhetetlen kelléke egy külön telepített Windows 32 bit-es windows xp, és az előző cikkben említett Windows XP Focusrite optimalizációk. De mi a teendő akkor, ha ezek után is a félelmetes Audio Dropout jelenséggel szembesülünk (minden jól működik, csak néha van pár ms szünet amikor nem)?
A valósidejű alkalmazások rendszerint kernel driverek szintjén kommunikálnak. Ha egy valósidejű driver drop-out-ol annak legvalószínűbb oka, hogy egy másik kernel szintű driver belerondít a képbe. Ezt rendszerint Deferred Procedure Calls (DPCs) nevű csodás interfészeken keresztül teszik.
Amennyiben ez a probléma, ezt elég egyszerűen megállapíthatjuk, az alábbi alkalmazással:
DPC latency checker
Segítségével mérhetjük a macimális DPC latency-t. Ha dropout van, és ezt látjuk a DPC latency-k alakulásán is, nem kell mást tenni, mint a Device manageren sorra kikapcsolni a kernel szintű drivereket használó eszközöket. A legintenzivebb ilyen cuccok általában a WLan kártyák, modemek, usb eszközök és vezérlők, integrált hangkártyák, nem standard ide driverek… Ezekre soha sincs szükség, kapcsoljuk ki őket… (érdemes minden esetben, nem csak ha probléma van, nehogy véletlenül legyen).
És kezdőthet is a móka (valós időben!)

Windows tűzfal (ipfw)

Nem nagy túlzás, ha azt állítjuk, hogy a mai világban egy jó tűzfal fontosabb, mint egy jó vírusirtó (persze ez utóbbi is fontos, de erről majd egy másik cikkben). A tűzfalakkal szemben személy szerint egy alapvető követelményem van: Lehessen egyértelmű módon megadni, milyen csomagot engedjen be és milyet ne. Linux alatt sok bonyodalom nincs, valahogy ott is úgy gondolják, ahogy én, és meg is született rá a megfelelő szoftverük az iptables.
Windows alatt picit komplikáltabb a helyzet. Nézzük meg mik a lehetőségek:

– Windows beépített tűzfal: valamit csinál valami alapján, használata nem ajánlott. Iskolapéldája annak, hogy lehet olyan tűzfalat készíteni ami mindent tud, csak a fenti egyszerű elvárást nem teljesíti.

– Zonealarm: van ingyenes, és ez jó, szinte minden beállítható az ingyenes verzióba, csak globális egyértelmű szabályok, és zónák nem…

– Comodo firewall (internet security): Comodo önmagában jó. Pár apróságtól eltekintve. Először is az önmagában szó sajnos csalóka, ugyanis nem tudták megállni, hogy az önmagában az csak Tűzfal legyen, adnak mellé minden féle protectiont, át is nevezték Firewall-ról Internet Security-re. Én személy szerint ki nem állhatom, hogy ha egy tűzfalat szeretnék 1-2 másik dolgot is kapok, de (szerencsére) a többi dolog kikapcsolható benne (bár valamennyivel több erőforrást eszik). Tudásban mindent tud, beállítható, érthető kezelőfelülete van (bár a Trusted Network-ök kezelése indokolatlanul bonyolult, és nem jól megoldott). Ráadásul egyszer miután kikapcsoltam, utána is éltek a Global Rules alatt beállított szabályok. Ezen még túltettem volna magam, de sok kapcsolatnál, és pár Global Rule alkalmazásnál iszonyú CPU használatot sikerült produkálni (iszonyú ebben az esetben nagyobb, mint 50%). Hát ez azért picit túlzás még egy internet security-ért is (jó tudom nagy az az internet, meg fontos a biztonság, de ennyire?)

Szóval a megoldás: wipfw (IPFIREWALL for windows)

egyszerű telepíteni, egyszerű beállítani, és működik. Aki nem járatos az iptables/ipfw rule kezelésben annak gondot jelenthet, de ha beéri az én biztonsági beállításaimmal, akkor telepítés után az alábbi dolgokat kell lefuttatni és működni fog.
Töröljük az összes beállítást:
ipfw -q flush
A beállítások minden bejövő csomagot tiltanak, kivéve a dhcp-t (hogy kapjunk ip címet):
ipfw add 00100 allow ip from any to any via lo*
ipfw add 00110 deny ip from 127.0.0.0/8 to any in
ipfw add 00120 deny ip from any to 127.0.0.0/8 in
ipfw add 00500 check-state
ipfw add 00501 deny ip from any to any frag
ipfw add 01500 allow udp from any 67 to any 68
ipfw add 01700 allow icmp from any to any icmptypes 3
ipfw add 01701 allow icmp from any to any icmptypes 4
ipfw add 01703 allow icmp from any to any icmptypes 0 in
ipfw add 01704 allow icmp from any to any icmptypes 11 in
ipfw add 65500 allow ip from me to any keep-state
ipfw add 65534 deny ip from any to any

Akinek kell windows file sharing:
ipfw add 01501 allow ip from any to any 135-139 in
ipfw add 01501 allow ip from any to any 445 in

Akik szeretnék, hogy a létrejött kapcsolatokat ne kelljen mindig újra felvenni:
ipfw add 00502 allow tcp from any to any established in

Az aktuális szabályokat kilistázni az ipfw list parancsal lehet. Törölni értelemszerűen az ipfw delete parancsal. Pl:
ipfw delete 00502

Ha valaki naplózni szeretné a történéseket akkor a log szócskát kell a szabályba írni:
ipfw add 65534 deny log ip from any to any
A napló helye: c:\WINDOWS\security\logs\wipfw{YYYYMMDD}.log

Az wipfw honlapja: http://wipfw.sourceforge.net/

How to Extend IBM Websphere 7 Trial Period

I would like to introduce two simple ways to extend (or eliminate) the Websphere Application Server trial period:

I. Delete the /properties/was.license file (when restarting the WAS7 server, the file will be recreated and the eval period restarts)

II. Use the java code below to generate your own license file… (the generated license file will never expire)


import java.io.File;
import java.io.FileOutputStream;
import java.io.ObjectOutputStream;
import java.util.Date;
public class WAS7LicGen {
public static void main(String[] args) throws Exception {
Date creationDate= new Date();
Date expirationDate=new Date();
FileOutputStream fos = new FileOutputStream(new File("./was.license"));
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeInt(0);
oos.writeObject(creationDate);
oos.writeObject(expirationDate);
oos.close();
fos.close();
}
}

IBM Was7 Trial Crack

Az ember azt hinné, hogy támogatják, ha azért dolgozik, hogy egy szoftvergyártó el tudja adni a piacon a nem túl jól sikerült megoldását. De nem. Minden alkalmazás szerver gyártó képes arra, hogy legyen fejlesztésre ingyenesen használható alkalmazásszervere… Kivétel ez alól a kék óriás, akinek csodaterméke azzal fogadott ma, hogy:

WSVR0027I: A termék 6 napon belül lejár.

Gondoltam ennek a felese tréfa, utána néztem a dolognak. Első körben nézzük, hol szerepel a hibaüzenet (WSVR0027I):

c:\work\IBM\WebSphere\AppServer\lib\bootstrap.jar\com\ibm\ws\bootstrap\TimeBomb.class

Hmm, nagyon ügyes… Én is pont olyan osztályba tenném az ilyen ellenőrzéseket, aminek cseppet sem árulkodó a neve…

A kódot elemezve az alábbi megállapításokat lehet tenni:
* A licenszet tartalmazó fájl helye: WAS7 könyvtár/properties/was.license
* Ha nincs ott még licensz fájl, a program kedves, és létrehozza nekünk… (tehát a fájl törölgetésével mindig 60 napunk lesz használni)
* A licensz fájl egy igen komplikált struktúrát használ (mondhatni egy igazi nagyvállalati megoldás). Van egy verziója (int) ami mindig 0-a, valamint tartalmaz két dátumot. Amennyiben ez a két dátum egyezik, akkor a licensz soha nem jár le…

Aki elő szeretne állítani magának egyet (ami nem jár le soha) az angol postban látható igen komplex programot kell megírnia…

Diskpart

Sokan nem tudják, de a microsoft az XP megjelenése óta nyújt megoldást a partíciók átméretezésére.
Az alkalmazás neve DiskPart.exe

használata:
Diskpart.exe

utánna az alábbi okosságokat lehet mondani: HELP 🙂

De a lényeg:

select disk 0 (primary ide, vagy 1)
detail disk (hogy valóban az e)
select volume 2
detail volume
extend

vagy
extend size=1024 (pl.: 1 GB)

És már kész is. Különösen hasznos ez, ha virtuális gépeket gyártunk, és elfogy a partíciórol a hely. Virtuális gépeknél amúgy is mindig használjunk dinamikus lemezt, és mondjuk 100 Gb-osat, így mindig csak annyi helyet fog használni amennyi a tényleges foglalás. Ha buták voltunk, és nem ezt tettük, akkor átméretezhetjük a lemezt a VDH Resizer nevű programmal, és utánna növelhetjük a méretét ügyesen.