Ha levetítjük, akkor 12Ft/munkanap az ára. Ez így jól is hangzik, de vajon mit kapunk három McChicken szendvics áráért. Milyen támogatásban részesít minket a nagy testvér?

Érdekes megközelítés az, amikor a nagy értékesítési mennyiség reményében olyan alacsony áron kerülnek forgalomba termékek, amelyek semmilyen módon nem tudják fedezni a velük járó költségeket. A kereskedelemben szabályozott, hogy bekerülési ár alatt nem értékesíthető semmi. De ez a szolgáltatási szektorban, ahova a szoftver is tartozik nem működhet. Csupán az jelenthet gátat, ha a minimális járulékokat sem fedezi, miközben legalább egy ügyfélszolgálatos kollégát fent kell tartani.

Az értékesítési partnerek is vonakodnának egy ilyen ár hallatán. 10%-os üzletszerzési jutalék esetén 288Ft/darab? Hmm…

Ön mit adna 2880Ft-ért, ha utána azt karban is kell tartani? Igen, igaza van, egy nagy semmit…

Kezdjük egy kicsit távolabbról. Évente jelennek meg újabb és újabb felhasználói élményt fokozó és a háttérben technológiai előrelépést jelentő fejlesztések. Gondoljunk csak (időrendben) a Java WebStart-ra, a Web2-re, az IWIW web-es átalakítására, amikor is nem HTTP POST-ok szaladgálnak a hálózaton, hanem AJAX-os kérések. Tovább is gondolhatjuk az ötletfolyamot! Vegyük észre a SilverLight előretörését, nem beszélve a web-es számlázókról, amelyek nem használhatóak ugyan nagy mennyiségű ügyfél gyors kiszolgálására, de megvan a maguk előnye hordozhatóság szempontjából. Nézzük csak meg a Vista widget-es megoldását, a hordozható miniszámítógépeken, PDA-kon megjelenő minialkalmazásokat, amelyek web-en mindent összekötnek. Nem utolsóként pedig a Google fejlesztéseit se felejtsük el, a GSM adótorony információkból meghatározott GPS koordináták kérdéskörét.

Ezek mind a felhasználókért vannak, az adatok valahol az interneten keringenek. A felhasználó a @google.com email címe alapján kerül azonosításra és a levelei mellett rögtön beszélgethet a barátaival, twitter-en hozzászólhat valamihez. Mindehhez 3 perc számítógép előtt eltöltött idő elég.

Vannak a nagy, céges rendszerek, a maguk 5-10 fős rendszergazda csapatával, adatbázis klasztereivel, központosított telepítési szabályaival. Nagy pénzintézeket, közmű szolgáltatók nem is tudnának másképp működni.

És vannak az otthon telepíthető, de mégis céges viszonyokat emuláló rendszerek. Ezek a dobozos ügyviteli rendszerek, amelyek közül már szinte csak a számlázórendszerek hálózatosak. A könyvelőprogramokat egy személy használja. (Általában – szerk.) Na ez MsSQL szrverrel olyan, mintha a webes google levelező helyett SmallBusiness szervert telepítenénk és csak Exchange szolgáltatáson keresztül levelezhetnénk. És mindezt a nagymamámnak kellene telepítenie. Fura, nem?

A cégek jelentős része MsSQL Express-t használ. Ingyenes, belefér a telepítőkészletbe, parancssorból telepíthető, gondozást nem igényel. De ez szerintem csak véletlen. Ez nem oda való! Ne gondoljuk, hogy azért mert laboratóriumi körülmények között működik, kiadható 100-1000, esetleg még több ügyfélnek és felelősséget lehet érte vállalni. Ehhez rendszergazda kell!

A Microsoft is határozottan jelzi, hogy van a nagyvállalati MsSQL szerver, annak a kis méretű kiadása hobbi informatikusoknak, 4GB terjedelemig. (De nem a nagymamámnak való!) És van az egygépes, telepítést és gondozást nem igénylő MsSQL compact (3.5) Ebben sajnos nincsenek meg a nagyvállalati működést támogató komponensek (triggerek, tárolt eljárások, stb.). De a célja nem is az, hogy dobozban áruljunk egy vállalatirányítási rendszert!

Az idő múlásával a fenti gondolat beigazolódni látszik. Már a .NET 3.5 is 1.5 órán át (!!!) települ, hozzá az SQL szerver még egy fél óra. Ez nem a dobozos kategória!

A Windows 7-tel ugyanez a probléma. A biztonsági házirend már nem engedi meg, hogy a felhasználó a webről bármit letöltsöm, majd az gyorsan telepítse. Annyi a kéretlen program, hogy már bizalmi elven nem telepítünk semmit. Azok a dobozos alkalmazások, amelyek még építenek arra, hogy “Úgyis lehet írni a program files-ba”, jobb esetben nem indulnak el, rosszabb esetben nem megfelelő működést eredményeznek. Erre példa a program files-ba telepített DBF-es számlázó Vista-n. Más-más felhasználóval belépve a Virtualizációnak “köszönhetően” ugyanyolyan sorszámú számlákat lehetett kiállítani és virtuálisan két számlázórendszer futott egymás mellett. Ez aztán az ügyvitel!

Kicsit hosszúra sikerült írásomat hadd zárjam egy élménnyel, amely egy Vista/Win7-re telepített ügyviteli rendszer indításakor ért. Egy MsSQL szerver-t használó programot telepítettem, de mégis további két alkalmazás kérte, hogy engedjem meg nekik publikus portok kinyitását. WTF? Az egyik alkalmazás egy MySQL szerver volt, a másik pedig egy Apache böngésző. A számlázóprogramom egy nem telepített, hanem csak odamásolt, tudja az ég milyen verziószámú szolgáltatást indított el és webszerverré tette a gépem. Abba már bele se merek gondolni, hogy mi lett volna, ha már van egy webszerver a gépen, amire telepítem (mert például az a cégünk belső intranetjének kiszolgálója)?

2009-ben már kevés, ha azt mondjuk, hogy működik ez, csak X, Y és Z gombot kell egyszerre megnyomni és valami valahonnan valahova kell másolni! A technológia és innováció legyen Veletek! Az MySQL és Apache párost hagyjátok meg másnak!

[Forrás]
Egyszer a követel van végrehajtható sikeresen, fatörzs távoli és fatörzs hátul -hoz lát a ügyintéző számla helyben. Ha sírnod kell megbénít hátul, típus a követel- háló felhasználó ügyintéző aktívság: és a ügyintéző számla lesz meghibásodott.

[Szerk.]
Ha helyben számlázol, akkor legyen távol és hátul egy fatörzs. Ha sírnod kell számlázáskor, ne aggódj, hátul meg leszel bénítva. De én nem hátul sírok…

[Forrás]
Mindig ön képessé tesz vagy megbénít a számla, lesz szükség -hoz fatörzs távoli vagy fatörzs -ban -hoz lát -ban tett.

[Szerk.]
A következő bekezdésben a számla bénít meg, de a fatörzs itt is jó szolgálatot tesz.

[Forrás]
Vagylagosan tudod is képessé tesz vagy megbénít a ügyintéző számla -ból Helyi Politika. Kettyenés -on elkezd étlap és típus secpol.msc -ban kutatás büfé és kettyenés belép.

[Szerk.]
Tehát vagy tudok számlázni vagy le leszek bénulva. És ehhez a politikának is köze van. De sebaj, mert kettyenés kell, amikor az étlapod kezded a büfében. A kettyenés az étlap előtt, a büfébe való belépéskor is kell.

[Szerk.]
Összefoglalva. A számlázás alapvetően egy fatörzzsel indul, de politikai behatásra kettyenés kell hozzá a büfében. A fatörzs itt lehet, hogy a büfében kapható sütemény típusa.

Lássunk egy ilyen statisztikát nálunk:

• Táblák: 73
• Mezők: 842
• Indexek: 103
• Egyediségi megszorítások: 24
• Idegen kulcsok: 221
• Tárolt eljárások: 26
• Triggerek: 23
• Kivételek: 9

“És ez még csak az egyik projektünk” lehetne hallani 10 évvel ezelőtt. Az adatbázisok normalizálása miatt a táblák száma már nem releváns információ. Persze (m)értéket képvisel két olyan rendszer összehasonlításakor, amikor egy 5 táblás és egy 470 táblás adatbázis találkozik.

De mi lehet akkor a modern kori mérőszám az üzleti logika mértékére? Nálunk a generált kód mennyisége az. Lássuk, mi mennyi:

• Sorok száma: 171.591 sor
• Karakterek száma: 5.784.477 betű
• Fájl bájtok: 13.779.968 bájt

Persze nem kézzel gépeltük ezt be. A kód generált, a saját üzleti logika erre épül. Annak mérete pedig titok…

Vajon az ok/mégse koncepciót a lusta programozók találták ki?
Mert miről is szól ez a dolog?! Az ember kitölt egy űrlapot, ami mondjuk az alkalmazottak adatait tartalmazza. Miután ezt kitöltöttük bezárjuk az űrlapot (Mentés/Ok gomb). Na most ha meg akarjuk nézni az adatlapot, akkor megnyitjuk a listából egy kivetítő ablakon, amit módosítani nem lehet. Bezárni a jól ismert X gombbal lehet. Ha módosítani szeretnénk, akkor megnyitjuk szerkesztésre. Majd bezárjuk a módosított űrlapot (Mentés/Ok gomb).

Tehát, ha új alkalmazottat veszünk fel és nincs Mentés vagy Ok gomb, akkor bezáráskor csak is akkor mentjük el, ha ki lett valami töltve. (Így nem kell Ok vagy Mentés gomb) Ha megnézésre nyitjuk meg, akkor kivetítő ablak. (csak x gombunk van úgyis) Ha módosítani szeretnénk, akkor megnyitjuk szerkesztésre az űrlapot és bezáráskor csak akkor mentjük el, ha változott. (Így sem kell Mentés vagy Ok gomb)

Viszont van egy hatalmas probléma, amit ezzel a módszerrel nem lehet kivédeni: az emberi tényező! Mert az ember egy olyan fajta, aki tévedni szokott. Ezért, megnyithat és beleszerkeszthet egy másik alkalmazott adatlapjába és csak módosítás közben jön rá -> Mégse gomb. Vagy rosszabb esetben kitöröl egy olyan mezőt, amit nem kellett volna, és nem emlékszik mi volt benne -> Mégse gomb, majd újra megnyit.

És mi volt ennek a gondolat mentenek a kiindulópontja? A Safari nevű böngésző beállítások “űrlapja”:

A kérdéssel és a koncepció elgondolásával jövőben projektjeinkben foglalkozni fogunk.

Egy érdekes, még éppen elolvasható hosszúságú bejegyzésre bukkatunk. Bevezetője is gondolatébresztő.

“2003 óta ismert a “ráguglizok” avagy angolban a “to google” kifejezés. 1998-as alapítása óta a Google naponta 200 millió keresést fogad, és vagyona akkorára növekedett, hogy alapítói méltán bekerülhatnek a világ leggazdagabb emberei listába. De felmerül egy kérdés: Honnan származik a Google pénze?

A cég az újításairól ismert. Na persze ez a fenti képen, amely az első google felületet mutatja 98-ból nem igazán látszik – hisz immár 11 éve ugyanaz az unalmas felület fogad minket. A stratégia egyszerű: Kell néhány fizetős szolgáltatás, majd a profitot a többi ingyenes szolgáltatásba nyomni. Így nő a népszerűség – még többen használják a fizetőseket, azt a pént ismét visszaforgatni és így továbbb… Ördögi kör.”

A teljes tartalom elolvasható itt: http://numlockholmes.blog.hu/2009/07/24/title_97900

Ha egy királyságban 25% áfát vetnek ki a polgárokra és egy termék nettó ára 9876 fabatka, akkor a bruttó árcímkén 12345 fabatka fog szerepelni.

9876 – 12345 minden számjegyet pontosan egyszer használtunk fel.

Van egy nagyon fontos dolog, amit egyszer sem említenek a programozásról és szoftverfejlesztésről szóló könyvek, és amiért néha félreértjük egymást. Te szoftverfejlesztő vagy. Én is. Ám nem biztos, hogy ugyanolyan céljaink és követelményeink vannak. Tulajdonképpen a szoftverfejlesztésből több fajta létezik, és mindegyik külön világra más és más szabályok érvényesek.

Ha egy UML-ről szóló könyvet olvasol, sehol sem találod meg benne, hogy az alkalmatlan eszközmeghajtók írásakor. Vagy olvashatsz egy olyan cikket, ami azt írja, hogy „A 20MB-s futtatókörnyezet (a .NET-hez) nem lehet akadály”, de nem mondja ki a nyílvánvalót: ha csak egy 32KB ROM-al rendelkező csipogóba írsz, akkor igenis van jelentősége!

Úgy gondolom, öt különálló világról beszélhetünk, amik néha átfedik egymást, de gyakran nem. Ezek:

1. dobozos
2. belső
3. beépített
4. játék
5. egyszer használatos

Ha a legújabb Extrém Programozásról szóló könyvet olvasol, vagy Steve McConnel remek könyveit, vagy akár a Joel on Software-t, esetleg a Software Development magazint, egy rakás olyan kijelentéssel találkozhatsz, hogy így vagy úgy fejlessz szoftvert, de arról nem szól a fáma, miféle fejlesztésről is beszélnek. Ez azért nem szerencsés, mert a különböző világokban lehetséges, hogy másképp kell csinálnod a dolgokat.

Nézzük át röviden a kategóriákat!

Dobozos az a szoftver, amit „a vadonban” használ nagy számú felhasználó. Talán még be is dobozolják, és a CompUSA-ban is árulják, de akár internetről letölthető is lehet. Lehet pénzes vagy shareware, nyílt forrású, GPL-es, akármi – a lényeg az, hogy akár ezrek vagy milliók használják.

A dobozos szoftvernek van néhány problémája, ami két különleges tulajdonságából adódik:

• mivel olyan sok felhasználó van, akiknek más megoldások is rendelkezésükre áll, a felhasználói felületnek az átlagosnál egyszerűbbnek kell lennie, hogy sikeres lehessen
• mivel olyan sok számítógépen kell futnia, a kódnak különösen rugalmasnak kell lennie, már ami a különböző konfigurációkat illeti. Múlt héten kaptam egy olyan hibát a CityDesk-re, ami csak lengyel Windows-nál fordul elő, mivel az operációs rendszerben a jobb Alt-ot kell használni a speciális karakterek beírásához. Kipróbáltuk Windows95-ön, 95OSR2-n, 98-an, 98SE-n, Me-n, NT 4.0-n, Win2000-en, és WinXP-n. Teszteltük IE 5.01-en, 5.5-ön, és 6.0-n. Teszteltük amerikai, spanyol, francia, héber, és kínai Windows-szal. Ám még nem foglalkoztunk lengyellel.

A dobozos szoftver három nagyobb fajtája létezik. A nyílt forrású szoftvert leggyakrabban úgy fejlesztik, hogy senki sem kap pénzt a fejlesztésért, ami a dinamikát nagyban befolyásolja. Például azokat a funkciókat, amik nem élvezetesek, nem készítik el a lelkesedésből fejlesztő csapat, és, ahogy Matthew Thomas ékesszólóan rámutat, ez a használhatóságot ronthatja. A fejlesztés valószínűleg nagy földrajzi távolságokat ölel át, ami a csapat kommunikációját radikálisan megváltoztathatja. A nyílt forrású világban elég ritka a személyes megbeszélés, ahol táblára dobozokat és nyilakat rajzolnak. Így a tervezési döntéseket, amik pont a dobozok és nyilak rajzolásából nyernék lényegüket, csak kis hatékonysággal hozzák meg. Végeredményben a földrajzilag szétszórt csapatok sokkal jobbak meglévő szoftverek lemásolásában, ahol elenyésző mennyiségű tervezés szükséges.

A tanácsadószoftver tulajdonképpen csak egy változata a dobozos szoftvernek, amit annyit kell finomhangolni és installálni, hogy egy sereg tanácsadóra van szükség a bevezetéshez, aranyárban. Többnyire a CRM és CMS csomagok esnek ebbe a kategóriába. Az ember könnyen úgy érezheti, hogy ezek valójában nem csinálnak semmit, és ez csak egy indok, hogy tanácsadók tucatjait szabadítsák rá, 300 dolláros órabérrel. Bár a tanácsadószoftver dobozos szoftvernek van álcázva, az implementáció magas költsége alapján inkább belső szoftvernek minősül.

A kereskedelmi webalapú szoftver, mint a Salesforce.com, vagy az eBay változatok még mindig igénylik a könnyű kezelhetőséget, és hogy minden böngészőn fussanak. Bár a fejlesztők megengedhetik maguknak azt a luxust, hogy (legalább egy kicsit) ellenőrizhessék a telepítési környezetet – a számítóközpontban levő gépeket –, kezelniük kell a böngészők széles skáláját, és a felhasználók nagy számát, így ezt én a dobozos szoftver kategóriájába sorolom.

A belső szoftvernek csak egy cég számítógépein kell futnia, ugyanolyan szituációban. Ezt lényegesen egyszerűbb fejleszteni. Számos olyat feltételezhetsz, ami a futási környezettel kapcsolatos. Megkövetelheted az Internet Explorer, a Microsoft Office, vagy akár a Windows egy verzióját. Ha grafikont akarsz csinálni, arra ott lesz az Excel. Nálunk mindenkinek van Excelje. (Ám próbálnád ugyanezt a dobozos szoftverednél, és már el is vesztetted a potenciális vásárlóid felét.)

A használhatóság kevésbé fontos, mivel csak meghatározott számú felhasználónak kell a programot használnia, és ők sem választhatnak másik szoftvert maguknak. A fejlesztési sebesség sokkal fontosabb. Mivel a fejlesztési költségek csak egy cégen belül oszlik el, az elosztható fejlesztési erőforrások is lényegesen kevesebbek. A Microsoft megengedheti magának, hogy ötszáz millió dollárt költsön egy operációs rendszer fejlesztésére, ami egy átlagembernek csak 80 dollárjába kerül. Ám amikor a Detroit Edison energiakereskedelmi szoftvert fejleszt, a befektetésnek ésszerűnek kell lennie az egész társaságnak. Értelmes ROI eléréséhez nem költhetsz annyit, amennyit egy dobozosra költenél. Így sajnos a belső szoftverek nagyon csúnyák.

A beépített szoftverek annyiban egyediek, hogy egy hardverbe kerülnek, és szinte sosem frissíthetők. Ez egy teljesen más világ. A minőségi követelmények itt sokkal magasabbak, mert nincs második lehetőség. Valószínűleg lényegesen lassabb processzorral kell dolgoznod, így sokkal több időt kell szánnod optimalizálásra. A gyorsaság lényegesebb, mint a kód szépsége. Kevesebb be- és kimeneti eszköz állhat rendelkezésre. A múlt héten bérelt autómban a GPS rendszer IO rendszere annyira szánalmas volt, ami szinte teljesen használhatatlanná tette. Próbáltál már ilyen ketyerén beírni egy címet? Megjelenik a képernyőn egy „billentyűzet”, és a nyilakkal kell kiválasztani az öt, egyenként 9 karaktert tartalmazó mátrixból a betűket (a link további illusztrációkat tartamaz a felhasználói felületről. A saját kocsimban levő GPS érintőképernyős, ami a felületet remekül feldobja. Ám elkalandoztam).

A játékok két okból kifolyólag egyediek. Előszöris a játékfejlesztések ökonómiája sikerorientált. Néhány játék sikeres lesz, de sokkal több van bukásra ítélve. Ha pénzt akarsz keresni a játékpiacon, jó, ha ezt felismered, és tartasz néhány sikeres játékot a portfóliódban, hogy a kirobbanó siker nyeresége fedezze a megbukott játékok veszteségeit. Ez inkább a filmszakmához hasonlít, mint szoftvereshez.

A játékfejlesztések nagyobb problémája az, hogy itt is csak egy verziód van. Ha már egy felhasználód végigjátszotta a Duke Nukem 3D-t, nem fog a Duke Nukem 3.1D-re frissíteni csak néhány hiba és pár új fegyver miatt. Néhány kivételtől eltekintve ha valaki már végigjátszott egy játékot, már unni fogja az újra játszást. Így a játékoknak ugyanolyan minőségi követelményeik vannak, mint a beépített szoftvereknek, és hihetetlen nagy pénzügyi szükséglet, hogy elsőre jó legyen. A dobozos szoftverek fejlesztőinek megadatott az a luxus, hogy ha az 1.0-ás verzió nem felelt meg az emberek igényeinek, a 2.0-s talán meg fog.

Végül az egyszer használatos kód az, amit csak azért ácsolsz össze ideiglenesen, hogy valami mást elérj, amit nagy valószínűséggel sosem kell többet használnod, miután azt a valamit elérted. Például írhatsz egy olyan kis shell szkriptet, ami egy bemeneti fájlt úgy masszíroz meg, hogy az olyan formátumba kerül, amit már valami más program már fel tud dolgozni.

Lehetnek még olyan szoftverfajták, amiket kifelejtettem.

Egy fontos dolgot tudnod kell: amikor olyan könyveket olvasol programozási metodológiákról, amiket egy teljes munkaidős szoftverfejlesztő guru / konzulens írt, szinte teljesen biztos, hogy belső céges szoftverfejlesztésről ír. Nem dobozos termékről, nem beépített szoftverről, és biztos, hogy nem játékról. Hogy miért? Mert a cégek bérlik fel ezeket a gurukat. Ők fizetik a számlát (hidd el, az id software nem fogja felvenni Ed Yourdon-t, hogy a struktúrált analízisről beszéljen).

Múlt héten Kent Beck azt állította, hogy valójában nincs is szükség hibakövető adatbázisokra, ha Extrém Programozást használsz, mert a páros programozás (folyamatos kódvizsgálattal) és a teszt-irányított fejlesztés (ami garantálja, hogy az automatikus tesztek 100%-osan lefedik a kódot) azt eredményezi, hogy nem lesz egy hibád sem. Ez valahogy nem tűnt igaznak a szememben. Bele is néztem a saját hibakövető adatbázisunkba, mi is az, ami elfoglal minket.

Na lám csak, azt vettem észre, hogy nagyon kevés hibát vettünk volna észre páros programozással, vagy teszt-irányított fejlesztéssel. A legtöbb „hibánk”, amit XP-ben történetnek hívnak tulajdonképpen fejlesztési kérések. A hibakövető rendszert egyszerűen arra használjuk, hogy ne felejtsük el, priorizáljuk, és menedzseljük azokat az apró csiszolásokat és nagy funkciókat, amiket ki akarunk fejleszteni.

Sok más hiba pedig csak akkor került a felszínre, amikor már a „mezőkön” régóta használták. A lengyel billentyűzet dolog. Ezt páros programozással lehetetlen észrevenni. Aztán azok a logikai tévedések, amik nálunk sosem jöttek elő úgy, ahogy a különböző funkciók együttműködnek. Minél nagyobb és bonyolultabb egy program, annál több a párbeszéd olyan funkciók között, amire nem is gondolsz. Egy bizonyos nem várt karaktersorozat (ha tudni akarod, a „{${?” az) összezavarja a lexert. Néhány ftp kiszolgáló hibát generál, ha egy olyan fájlt akarsz törölni, ami nem is létezik (a mi ftp kiszolgálónk nem kiabál, így ez elő sem fordult nálunk).

Figyelmesen végigtanulmányoztam az összes hibát. 106 hiba közül, amit a CityDesk szervízcsomag kiadásában megjavítottunk, pontosan ötöt tudtunk volna páros programozással, vagy teszt-vezérelt tervezéssel kivédeni. Sokkal több hibánk volt olyan, amikről tudtunk, amikről úgy gondoltuk, nem fontosak (kivéve persze a vásárlóinkat!), mint olyanok, amiket az XP módszerrel kivédhettünk volna.

Ám Kent-nek igaza van a másik fajta fejlesztésben. A legtöbb céges fejlesztésű alkalmazásnál ezek egyike sem lett volna hiba. A program lefagy érvénytelen bevitelkor? Futtasd újra, de ezúttal figyelj a {${?-kre! Aztán úgyis csak egy fajta ftp kiszolgáló lesz, és a cégben senki sem fog lengyel Windows-t használni.

A szoftverfejlesztés legnagyobb része ugyanaz, akármiféle projekten is dolgozol, de nem teljesen. Ha valaki metodológiáról beszél, gondolkodj el azon, hogy ez hogy hatna a te munkádra. Gondolkodj el azon, hogy milyen környezetben is van a másik. Steve McConnell, Steve Maguire, és jómagam egy nagyon szűk sarokból jövünk: a dobozos tömegcikk táblázatkezelő alkalmazások világából, amit Redmondban, Washington államban írtak. Nálunk magasabb a léc az egyszerű használatnál, és alacsonyabb a hibáknál. Az összes többi módszertan guru azzal keresi a betevőt, hogy konzultál saját céges fejlesztéseknél, és ők erről is beszélnek. Bárhogyis, mindannyian tudnunk kellene tanulni egymástól.

Forrás: http://js.hu/jos/

• Precíz információkkal szolgáltak a kreatív elkészítéséhez (PSD források, leírás).
• Gördülékenyen intézték a rendelésfelvételt
• Határidőre teljesítették a vállalásukat

Az elkészült anyag (tok+lemez) mindenben megfelel az elvárásainknak.

www.szuperlemez.hu

Évekkel ezelőtt nem értettük, hogy miért “éri meg” egy nem operációs rendszerbeli programmal elváltoztatni azt a kinézetet, amit nagy cégek verejtékes munkával összeraktak. De már tudjuk, hogy mindenki egy kicsit egyedit szeretne, kicsit szeretné a sajátjának érezni a számítógépet abban a 8 órában, amig előtte ül.

Pár hónappal ezelőtt ezért határoztuk el, hogy minden rendszerünkben a felhasználó testreszabhatja a kinézetet. Kicserélheti a háttérképet, beillesztheti a háttérbe gyermekét, kutyáját vagy akár ellenségét…

További képernyőket nézhetünk meg ide kattintva!

Ezen kívül pedig választhat számos előredefiniált kinézet közül. Lássuk, mit láthatunk!

MacOS

“Új hullám”

A Sötét iroda bűvöletében

Mi mindenből lehet választani…

Nemsokára megjelenik Windows7 (seven) operációs rendszert idéző kinézetünk is…

A LAB oldalon megjelenő információknál több, kevésbé szakmai hirdetményeket jelenítünk meg.

Kövess minket Te is itt: SymbolTech on Twitter

Annyira régi, annyira elterjedt, hogy bele sem gondolunk, azt valószínűsíthetnénk, hogy Kolombusz ültette el az első Admin fát az újvilágban vagy az amerikai kontinens Kazinczy-ja lehetett az első, aki ezt a kifejezést alkalmazta.

Csapatunkat mégsem hagyta nyugodni a dolog. Szóösszetételekben gondolkodtunk és beugrott egy kifejezés összetétel: Ad-Ministrator. A ministrator a miniszter szóra hasonlít, a latin minister-ből eredhet, ami szolgát jelent. Ennek politikai, közigazgatási jelentősségét most ne firtassuk! Az Ad pedig nyilvánvalóan hirdetést jelent, újkori rövidítése a szintén újkori advertisement szónak. (Ennek latin forrása nincs, régi korokban nem volt hirdetés).

Talán ráhibáztunk a kialakulás módjára is. A web-es, elektronikus hirdetések szolgáját, aki kezelte, adminisztrálta (önmagával magyarázzuk a dolgot?) a hirdetéseket hívhatták AdMinistratornak. Az, hogy a számítógéphez jól értő emberek a hirdetések mellett más dolgokat is kezeltek, nyilvánvaló következménye az eseményeknek.

A nálunk dolgozó Ad Miniszterek (adatbázis, IIS, Small Business) kérjük ne érezzék rosszul magukat a szolga szó olvasása közben, csapatunk nagyrabecsült tagjai ők, a szó régi jelentését már elfelejtettük.

Eddigi fejlesztési tapasztalataink alapján összeszedtük, hogy mikkel találkoztunk eddig. Nem titok és nem szégyen, velünk is előfordul, mi is mulasztottunk már:

Direkt lassítás. Nem károkozás, sokkal inkább professzionális munkamódszer, amikor lassabb számítógépet emulálva szándékos lassításokat helyezünk el a kódban. Nem célszerű ezt a kiadott verzióban is benne felejteni.
Megoldás: #warning pragma használata

Felugró ablakok. Hibakeresési céllal sok programozó használ felugró ablakokat, sőt – bár nem illik, de néha az átlagosnál durvább verbális kifejezéseket is. Mivel ezek hibafelderítési célokat szolgálnak, általában ott maradnak benne a kódban, ahol csak alapos tesztelés során talál rá az ember/tesztelő. A végfelhasználónál megjelenő, nem értelmezhető, oda nem illő üzenetek presztízsrombolók.
Megoldás: Üzenet megjelenítése Debug.WriteLine()-nal.

A bűvös new Random(). A végfelhasználó nem veszi észre mindig, de számos helyen alkalmazunk véletlen tesztadatokkal való feltöltést. Nem szerencsés, ha a végfelhasználónál történő új vevő rögzítéskor a vevő neve és címe már kitöltésre került tipikusan “Kovács Géza” és “Kiss János” nevekkel.
Megoldás: new Random() konstruktorok megkeresése a forráskódokban.
Saját tapasztalat: Nem minden ilyen konstruktor kell, hogy megszűntetésre kerüljön. Legutolsó projektünk a tisztítás után 7 helyen használta a Random konstruktort.

Ideiglenes fájlok írása. XML vagy bármilyen más adatátvitel implementálása közben gyakran mentjük az átvitt adatokat átmeneti fájlokba. Sok esetben ez a C:\tempfile.dat, amely azon kívül, hogy az ügyfél számítógépén furcsán mutat, rendes biztonsági házirendet tartalmazó környezetben (a fájlírás letiltása miatt) IOException-t eredményez.
Megoldás: if DEBUG direktíva használata fájl írásakor.

Takarításra fel!