Pályafutásom kezdetén, a CCS Hungary Kft-nél szoftverrendszert fejlesztettünk, amely a légitársaságokat és a Malév-ot szolgálta ki. Egyik funkciója volt a csomagok gépre rakása. Ha a gép indulása előtt negyed órával volt még függőben lévő csomag, akkor különleges figyelmeztetést kellett megjeleníteni.

Jött a korszakalkotó ötlet, hogy ne csak vizuális, hanem “audiális” is legyen a figyelmeztetés. A villogó piros mellett 5mp-enként hangot is adott. Kis sípolós kattanás. A szoftver rendben volt, vittük telepíteni.

A telepítésnél ott voltam, ezért én kaptam az első “pofont”. Az automatikus frissítő rendszer kb. 30 gépre lerántotta az alkalmazást és a felhasználó tényleges feladatától függetlenül minden gépen jelzett a csipogó. 5mp-enként szólalt meg ugyan, de 30 számítógép esetén ez 6csipogás/mp-es ütemezést jelentett. Egy nagy terem, ami csipog. A csipogás mellett már sikítottak is a kollégák. Nagy zűrzavart okoztunk

Szóval ezért nem szeretjük a hangokat. De az üzleti felhasználás most megkövetelte. A felugró emlékeztető (Partnerkapcsolat modul) és az átküldött jegyzet (Sticky-note) hangot ad, amikor megjelenik. Reméljük, nem lesz belőle hangorkán.

Ingyenes megoldás

Adatbázis műveleteink optimalizáltsága miatt egy 2/2 Mbit-es kapcsolaton működő szerver (amely lehet Linux is) alkalmas a rendszer kiszolgálására 15 munkaállomásig. A munkaállomások számának növekedésével felfelé skálázni kell a kapcsolat sebességét.

A kapcsolat nyilvánvalóan publikus, bárki számára elérhető, emiatt lehet hozzá egyszerűen csatlakozni. De nézzük meg, milyen információkat kell tudnunk ahhoz, hogy a kapcsolat létrejöhessen. Szükség van tehát:

• IP címre vagy host névre
• port számra (alapértelmezett 3050 helyett)
• adatbázisfájl fizikai helyének megadására

Az első kettő a mai számítógépes teljesítménnyel pár óra alatt kideríthető, ha máshogy nem, próbálkozással. A legutolsó azonban olyan mértékű kombinációs lehetőséget jelent, hogy számítógép legyen a talpán, aki ezt kitalálja. Nézzük, milyen példák lehetnek:

Windows-on: c:\SymbolUgyvitelDB\kiscegem\db1\default.database

Linux-on: /var/lib/database/Symbol/CoMPaNY_1580/default.database

Ez utóbbi még betűnagyság érzékeny is. Matematikus kollégák véleménye szerint a lehetőségek száma elég nagy ahhoz, hogy valaki ezt ne találhassa ki. Konkrétan 26*2+10+5 a 49-ik hatványon, ami egy 3-as és mögötte 89 (!!!) darab nulla. Szemléltetve ez ennyi:

1 :

30000000000000000000000000000

000000000000000000000000000000

0000000000000000000000000000000

Azaz kicsi az esélye, hogy valaki el tudja találni, hol az adatbázisom. Ezt még egy kicsit erősíteni lehet, ha a helyet havonta cseréljük.

Ingyenes, előkészületet igénylő megoldás

Továbbra is ingyenes, de felkészültséget igénylő megoldás a kézzel kiépített SSL tunnel. Ezt például a putty programmal is megtehetjük. Ilyenkor az előző biztonságot növeljük azzal, hogy titkosított csatornán keresztül közlekednek az adatok. A csatorna kiépítése ilyenkor a felhasználó feladata.

Vállalati meegoldás, VPN

Egy igazi megoldás, amely pénzbe kerül a Virtual Private Network. Ez egy virtuálisan kiépített helyi hálózat, amely a számítógépet úgy emulálja, mintha a számítógép az irodában lenne. Ehhez valamilyen VPN szerverre szükség van.

…nevet még nem írhatok

Egy nemsokára megszülető megoldásunk – amelynek van már neve, de nem publikus – célja ponz az lesz, hogy biztonságos és stabil infrastruktúrális megoldást biztosítsunk ügyfeleinknek. Erről majd később.

A biztosítékot az csapta ki, hogy az ESZIG nyomtatvány mezőnevei az IMP/XML fájlban ugyanolyan véletlenszerűen vannak, mintha egy jó véletlenszám generátort készítenének az adóhatóságnál. (Bocs, helyesen NAV). Néha láttunk benne szabályszerűséget, de a végén nem sikerült semmilyen elvet ráhúzni. Maradt a kódtáblázat, azaz sor+oszlop-hoz hozzárendeltünk egy számot, ami az azonosítója lett a mezőnek.

Kérdésem az, hogy milyen szabályok alapján határozták meg a mezők azonosítóját. Esetleg több lépcsős módosítás során álltak elő a számok? A lényeg, hogy egyelőre sikerül megvalósítanunk a dolgot, de egy publikus API ennél okosabb/logikusabb is lehetne…

És, hogy mit látunk?

• Van olyan cég, amely 2009. év közepe óta nem jelentetett meg hírt magáról. A saját weboldalán! Leszálló ág, vélelmezhető, hogy csökkenő Incoming Cash-sel rendelkeznek…
• Van, aki szépen csendben fejleszt, 2 havonta kiad egy új verziót, benne apróbb gombok, kis kényelmi funkciók. Lelkes csapat, Csendes folyó, 1-et fizet x-et kap (x>=3) akcióval…
• Van régi motoros, régi V12-es. Sokat fogyaszt (termékkövetés), már nem annyira hatékony és a kasztni is itt-ott kopott. Slusszkulcsának pörgetésével, kapuzárás előtti sofőrjével még bejön néhány hölgynek…
• Van, aki újként indult, rögtön v3.0-ként jelzi rendszerét. Szépen felépített koncepció, egyszerű kezelhetőség, 4 számjegyű árak. (És valahol máshol már látott működési modell, ismerős MsSQL instance név, ablakok) Naturalisztikus bulvártermék, csak bírja ügyfélszolgálattal… szurkolunk.
• És még sokan mások…

Ki mutat újat?

Örömmel tölt el minket az a fellelhető irányvonal, hogy tudunk még nekik is újat mutatni. Több megvalósult fejlesztésünk köszön vissza a versenytársak termékeiben. A maguk módján. Biztos, hogy nem napi szinten foglalkoznak velünk. Ez nem is lenne jó. De néha észreveszik, hogy mit csináltunk és ötletet merítenek belőle/belőlünk.

Több forrásból értesültünk, hogy fejlesztéseinket elemzik is. Tudjuk, hogy az egyik cég a Symboogle és a Symbol Suggest megoldásainkat nem tartja jó ötletnek. Mások a jelenlegi CRM+ rendszerünkre ráharaptak, jelenleg 12 hónapos fejlesztési feladatként még kicsit halogatják. (Nemsokára CRM+ rendszerünk még nagyobb tudású lesz)

Fontos megjegyezni, hogy ez nem tilos, sőt jó. Mert előre viszi a világot. És két dolgot bizonyít számunkra:

1. Jó úton haladunk, ötleteink nem csak számunkra bírnak értékkel.
2. Többedik alkalommal elemezve azt, ahogy minket követnek, azaz INNOVATÍV PIACVEZETŐK vagyunk.

Mitől versenytárs?

Itt álljon egy kis magyarázat arra vonatkozóan, hogy mitől versenytársak. A konkurens ugyanazt adja más köntösben, talán apróbb paramétereiben eltérően (nagyobb internet sávszélesség, nagyobb GB, +25% a samponos flakonban, ugyanaz a mobiltelefon olcsóbban WiFi nélkül), de végeredményben ugyanarra jó. Itt azonban versenytársakról beszélünk, akik egy pályán haladnak, versenyeznek. De nem ugyanazzal a járművel mennek, sőt valaki tankkal tör előre, van aki versenybiciklivel hagyja le a tankot a kanyarban.

De nincs célszalag, nincs győztes, nincs a legjobb. Ez egy folyamatos verseny…

Van, aki 100m után hagyja abba, van, aki fut még 3 kört és valaki lefutja a fél-maratont. Mert mást akar elérni a pályán, a piacon.

Emiatt nem a megtett körök (=megszerzett ügyfelek) száma a fontos, sokkal inkább a futás stílusa és főleg az, hogy ki fut legelöl, kit követnek a többiek. Mi ezek szeretnénk lenni, sőt mi ezek vagyunk. Jelenleg. Lehet, hogy jön egy új versenyző, tele erővel és ötletekkel. De addig maradunk elöl. Köszönjük a megtisztelő figyelmet!

Kérem kövessenek!

ps: régi feladvány a ’80-as évekből

“Hányadik leszel, ha futóversenyen megelőzöd a második helyezettet?”
Általános válasz, hogy első, de a helyes válasz a második

Tegnapi nap folyamán érkeztek a bejelentések, hogy az EU közösségi adószámok ellenőrzése nem mindig jó. Megvizsgálva azt láttuk, hogy az URL megváltozott. De mint kiderült, nem csak az URL, hanem az adatok formátuma is megváltozott. De erről sajnos nem kaptunk értesítést.

Ez azért zavaró, mert egy szolgáltatást veszünk igénybe, amelyet továbbadunk ügyfeleink felé. És ők joggal panaszkodnak.

Tapasztalat, hogy a SaaS-ként emlegetett szolgáltatásokban azért annyire nem érdemes megbízni!

Minden kérdésére készségesen válaszolt Balázs Csaba fejlesztési vezetőnk, aki talán a legkompetensebb a témában.

FP: Miért ilyen gyakran?
BCS: Röviden? Mert képesek vagyunk rá.

FP: És kicsit hosszabban?
BCS: Van mit és tudjuk, hogy hogyan. Általában 3-4 heti gyakorisággal gyűlik össze annyi újdonság, hogy érdemes legyen egy csomagként megjelentetni. Próbálkoztunk már kéthavi kiadással, de olyan mennyiségű volt az újdonság, hogy két nyílt napon tudtuk csak bemutatni a programot. Pontosítok, a program újdonságait.

FP: Ennyi javítanivaló van?
BCS: Újdonságokat említettem az előbb is. Újdonságok teszik ki a fejlesztés 75-80%-át. Van benne javítás is, ezek általában apróbb felhasználói visszajelzések, nem komoly hibák. És igen, több, mint 3/4-e újdonság. Ezek vagy a programunk újdonságai, vagy valóban ügyviteli újdonságok.

FP: Valóban folyamatos a fejlesztés?
BCS: A jó szoftver sosincs kész. Ahhoz a programhoz nem készülnek új fejlesztések, amelyet nem használnak. Nálunk, a folyamatos használatból adódóan mindig merülnek fel igények.

FP: És ezeket a programba beépítitek?
BCS: Mindig mosolyogni szoktam a felhasználói igényeken, persze nem gúnyosan. Elmondhatjuk, hogy nagyon ritka a valóban új igény. A programunk alapja egy négy generációt megélt ügyviteli rendszer, amelyet cégünk egy akvizíció során már magáénak tudhat. Ezen a négy verzión már nagyon sokat tapasztaltunk. Legyen szó általános igényekről vagy speciális üzleti folyamatról, a nagy részük már tervbe van véve nálunk. Azaz nemsokára a polcról tudjuk kiszolgálni az olyan igényeket is, mint a munkaruha kihordási idő nyilvántartása. Tavaly év végén 2011.decemberéig volt meg a fejlesztéi tervünk, van mit csinálni.

FP: És most?
BCS: 2012. Karácsonya is munkával fog telni (nevet)

FP: Érdemes akkor még várnom 24 hónapot?
BCS: Dehogy! A termékünk a maga nemében már megjelenése után jól állta a sarat, mert szükség volt valami modern rendszerre. Az akkori rendszerek 6-10 éve készültek, ebből adódóan legalább 7-11 éves technológiával. Felkevertük az állóvizet. A termék egy évvel a megjelenése után jól szerepel, számos funkciójában lekörözte versenytársait.

FP: De ha még nálatok is vannak fejlesztési tervek, akkor más, 6-8 éves termékekben ezek miért nem találhatóak meg?
BCS: Megtalálhatóak. A maguk módján. Minden rendes ügyviteli szoftver megvalósítja az évek során összegyűlt funkciókat, de azok vagy ügyfél igények alapján készültek – ügyviteli szakértelem nélkül – vagy csak fejlesztői gondolatokat figyelembe véve. Ez pedig a valóságtól messze van. De egy még fontosabbat kiemelnék, a precizitást. Minden dolgot több féle módon megvalósíthatunk, de kevés termék van, ami a felhasználói kényelmet és a legapróbb igényt is megvalósítja. Mi erre törekszünk, azaz hogy legyen élmény az ügyvitel!

FP: Mondasz erre egy példát?
BCS: Jó példa a gyári szám kezelés. Minden szoftverterméknek része, de vajon használható-e? Nálunk nem az a cél, hogy a gyári számok a számlán megjelenjenek, hanem valóban ki tudjam mutatni, hogy milyen gyári szám hányszor és mikor fordult meg nálam. És ezt még Symbol-osan megspékeljük azzal, hogy termékenként a gyári szám bevitele maszkolható. Azaz mobiltelefonoknál nem tudunk nem 15 jegyű IMEI számot beírni, nem tudjuk elgépelni.

FP: Azt hiszem, erre mondjátok, hogy innovatív
BCS: Meg az egészre, amit itt csinálunk. 80% gondolkodás, 20% munka.

FP: Elején említetted, hogy tudjátok a hogyant is. A konkurencia nem tudja?
BCS: Pontosítsunk. Nem szeretem a konkurencia szót. Azt sugallja, hogy egy van, aki a legjobb és a végén is csak egy maradhat. Inkább használjuk a versenytárs szót, hiszen verseny azért van.

FP: Szóval, a versenytársak nem ismerik a hogyant?
BCS: Mindenki ismeri a saját hogyanját. A miénk lehetővé teszi, hogy 3-4 hetente kiadjunk egy verziót, amely az ország több száz számítógépén tökéletesen frissül – még soha nem volt ezzel kapcsolatban hiba – és megoldást szállít a problémákra. Sokáig terveztük a saját rendszerünket, a cél pont az volt, hogy könnyen tudjunk hozzáilleszteni, könnyen lehessen bővíteni.

FP: Említetted, hogy problémák vannak…
BCS: Mindenkinek, Neked is, ha valami nem működik vagy nem elég hatékony, akkor az probléma. A remek ötleteidet rajtad kívül álló okok miatt nem tudod megvalósítani, a fránya számítógép vagy a számlatömb a szűk keresztmetszet. Ezek a problémák, amikre megoldást nyújtunk. Valódi megoldásokat.

FP: Mik a jövőbeni tervek?
BCS: Decemberben is marad a 3 heti gyakoriság, sőt egy kicsit bele is húzunk, két kiadás is lesz. Amíg a többiek pihennek, addig mi dolgozunk, mert az ügyvitel a szenvedélyünk. (nevet) Ismét 42 újdonságra jut 13 javítás, módosítás, lesz benne iparági újdonság is, mint amilyen a Symboogle volt. De erről többet majd a szoftverkiadáskor.

FP: 2012 decemberében folytatjuk a beszélgetést?
BCS: Ismételjük meg gyakrabban! Büszkék vagyunk a munkánkra, ezt kívánjuk továbbra is csinálni. Nagyon jó visszajelzések érkeznek. A kedvencem a: “Hol voltak maguk idáig???“

A Symbol LAB több változat eldobása után egy felhasználói élményekben és főleg operatív használhatóságban élenjáró megoldással örvendezteti meg jelenlegi és jövőbeni ügyfeleit.

A végleges fejlesztés sok munkaórát igényel még, várhatóan jövő év első heteiben jelenik meg, de egy pár képernyőképpel már most is szolgálhatunk, a tervezési fázis állapotáról.

A képlopó program nem volt képes az egérkurzort a képernyővel együtt menteni, ezért nem látható. De várjuk csak ki a végét! Nem csak sima egérkurzorról lesz szó… Fogd és vidd újraTÖltve!

A Google megváltoztatta a világot a mindenre kiterjedő, szavak – a gyakorlatban szinte gondolatok – alapján történő kereséssel. Azt is kitalálja, mire is akartunk keresni. Ha nincs sok találat, ajánlást tesz arra is, hogy mire kellene keresnünk. Egyszóval okos.

A Google az Interneten keresgél, a Symboogle-val ugyanezt tervezzük megvalósítani ügyviteli adataink között. Mindenre, mindenhol. Symboogle.

Ezek szerint az új számítógépet vásárlók már nem biztos, hogy tisztában vannak vele, mit is vásárolnak. A népszerű programok futnak a számítógépükön, de mi lesz az ügyvitellel?

A Symbol Ügyvitel minden változata alkalmas 64bites operiációs rendszeren való futattásra:

• Windows XP 64
• Windows Vista 64
• Windows 7 64
• Windows 2008 x64

És természetesen Linux kiszolgálót választva minden 64bites Linux disztribúciót támogatunk, ami fut a Firebird adatbázis-kiszolgáló.

Külön kerül értékesítésre a fehér színű fejlesztői változat és a fekete végfelhasználói.

Fejlesztői változat tartalmazza:

• Surface Software license consisting of Surface Platform runtime 1.0 SP1 software
• Windows Vista Business SP1
• Surface SDK 1.0 SP1

A végfelhasználói változatnak nem része az SDK. Talán ezét kerül többe (!!!) a fejlesztői változat. Pedig a logikus az lenne, ha a promóció miatt a fejlesztés olcsóbb lenne. Úgyis meg kell venni a végfelhasználóit, ha telepíteni is akarom a célközönségnél.

Az ára 13.000€, azaz kicsit több, mint 3.5M Ft. Nem kevés, de minden bizonnyal az elterjedés után nyomottabb áron is elérhető lesz.

Természetesen cserealkatrészek is elérhetőek hozzá.

Elérhető itt: http://www.microsoft.com/surface/Pages/HowToBuy/HowToBuy.aspx

(Symbol Ügyvitel is FB 2.1 alapokon fut, ennek architektúrális okai vannak, a Delphi-s indíttatás elenyésző – a szerk.)

És közben magát nagyon jól pozicionálva megjelent a VistaDB4. http://www.vistadb.net/vistadb

Talán régebben választották neki a nevet, mint ahogy a Microsoft operációs rendszere megszületett.

Mit is tud általában?

Beépített. Ez azt jelenti, hogy nem kell szervert telepíteni, minden művelet, megoldás az applikációban kap helyet.

T-SQL-t érti. Az MsSQL tárolt eljárás nyelvét egy az egyben futattni képes, sőt a CLR-t is fel tudja használni.

MSSQL funkciók. Számos olyan funkció beépítésre került, amely a “nagy” MsSQL-nek része, de a CE (compact edition) változat nem tatalmazza: triggerek, tárolt eljárások. Így alternatívája lehet az MSDE/MsSQL-CE-nek.

Mi egyebet kapunk?

• Visual Studio integráció
• Adatmodellező eszköz
• .NET framework teljes integráció

 Mibe kerül ez nekünk?

• Természetesen ára van, mert semmi nincs ingyen.
• $59 az alapértelmezett, Light csomag, ebben sajnos kevés a funkcionalitás.
• $359 az ideális választás /fejlesztő.
• A runtime komponensek felhasználókhoz való eljuttatása természetesen ingyenes.

Jó választás, jó a verseny, egy kiforrott alternatíva lehetősége a korábbiak mellett, amelyek már kinövik saját méretüket. Lásd MsSQL 200MB-os telepítő!

VistaDB

Mindenki, aki ilyen típusú autóval kereskedik, saját cégneve alatt létrehoz egy domain-t (www.bmw-cegnev-kft.hu), majd keresőbaráttá teszi. És tőle vásárolnak. Most egy még újabb trend-forduló van kialakulóban. Még cselesebb!

Sok cégnek nem sikerült említésre méltó brand-et kialakítani vagy pont presztízs veszteség(!!!) lenne a cégnevet feltüntetni. És kialakult a www.a-termekcsoport-neve.hu domain felépítés. Lássunk néhány példát erre:

ARendszergazda Kft. által üzemeltetett, kifejezetten értékesítési célú weboldal:
www.a-szamlazo-program.com

Diamond Stúdió Kft cégkapcsolatait kihasználó:
www.ugyvitel.com

QualitySoft Kft célirányos domainje:
www.szamvitelirendszer.hu

Természetesen nem emelhetünk kifogást minden ellen, ami tartalmaz valamilyen célravezető fogalmat. A www.ugyvitelbazis.hu neve hűen tükrözi azt, amivel foglalkoznak. A leginkább polgárpukkasztóak az olyan domainek, amelyek a/az névelővel kezdődnek:

www.akereskedo.hu

www.abroker.hu

www.abolt.hu

www.akereso.hu

(www.atv.hu nem tartozik ebbe a kategóriába, nekik a brand nevük kezdődik A-val!)

Még messze vagyunk tőle, hogy ez a félrevezetés kategóriájába tartozzon jogilag, hiszen, amit nem tilos, azt szabad. De megkérdőjelezhető, hogy a www.az-ugyviteli-program.hu domain mennyire félrevezető, hiszen azt az érzést kelti, hogy ez a termék a piac legjobbja, sőt csak ez létezik a nagyvilágban.

(Elnézést mindenkitől, aki a listában nem szeretne szerepelni, de egy kis link-marketing-ért csak nem fog neheztelni!)

Bonyolultságát tekintve már évek óta (SQL2000/MSDE) olyan tudású volt az adatbázis szerver, hogy ahhoz rendszergazdára volt szükség. A 2005/2008 telepítése pedig már több időt vett igénybe, mint egy Windows7 telepítés. Az adatbázis szerver bizonyított nagy rendszerek esetében is. A lépés, hogy az Oracle-lel konkuráljon, logikus volt.

De mi lesz a kis felhasználókkal? Számukra továbbra is lehetőség nyílik az Express változatra, de azt sajnos el kell felejteni, hogy egy 50MB-os telepítőbe belezsúfolva, csak úgy mellékesen a gépre települ a DBserver.

A Microsoft-nak erre is van megoldása:

1. MsSQL CE néven fut a kicsit butácska SQL server, amelyben nincs trigger, tárolt eljárás. Viszont egy gépen fut.
2. Másik megoldás a rendszergazdával ellátott céges számítógépes rendszer. Végy egy rendszergazdát (hiszen ki tartja karban a licenszkulcsokat, ki frissíti a gépeket, ki szerzi be a tonert, stb.), aki feltelepíti az SQL szervert, beállítja a jogosultságokat és telepíti az ügyviteli rendszert.

Lassan ideje elgondolkozni, hogy milyen dobozos alternatívái vannak az MsSQL servernek!

Addig is az újdonságok: http://www.microsoft.com/sqlserver/2008/en/us/whats-new.aspx

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…

Persze nem kell kivágni, elég felírni a promóciós kódot és nálunk például a Symbol Ügyvitel vásárlásánál beváltható a kedvezmény.

A Symbol Ügyvitel kupon itt elérhető: Symbol Ügyvitel kupon

Egyébként ezt integrálták a Google Maps szolgáltatásba, azaz gyakorlati haszna a cég üzletének térképen való megjelenítése és a térképes találat meghálálása egy kuponnal.

Persze tartozik hozzá Google API is, azaz programozottan is elérhető, nem kell a cégvezetőnek egész nap a google weboldalán kattintgatnia: http://code.google.com/intl/hu/apis/coupons/

Új számológép. A calc.exe megújult. Tud dátumok közt különbséget számolni, autólizing maradványértékben gondolkodni. És közben az adatokat programozói módban megjeleníteni, ha jól láttam 128bites adatok formájában is.

Beépített Sticky-notes. Soha nem bíztam a 3rd party alkalmazásokban, ezért nem volt ilyen alkalmazásom. De most lehet, hogy a saját asztalomra teszem az eddig notebookra ragasztott sárga kis cetliket. Arról nem beszélve, hogy a színét is tudom változtatni, nem számít, hogy milyet lehet kapni az OfficeDepot-ban.

Letölthető HUN. Igen, végre elékeztünk oda, hogy a Windows7 nem kerül kiadásra EN, majd HU nyelven, hanem egy-egy 40MB-os letölthető csomag segítségével a felhasználói felület magyarítható. Ki/bejelentkezés kell hozzá és a Welcome szüveg nem lesz magyar a login-kor, de minden program nyelve megváltozik. Újratelepítés nélkül. 2009-ben már ideje volt.

Pasziánsz is új. Ez is megváltozott. Félek leírni, de tényleg elhihetitek, hogy csak azért indítottam el, hogy kipróbáljam hátha a számológéppel ez is megújult. És igen.

Shield-ikon. Shield ikon kék-sárga lett. Az eddigi színes jobban tetszett, de majd ezt is megszokom.

Vezérlőpult. ControlPanel lenne a neve, de ugye a 40MB-os HUN csomag. Méginkább böngészős (vissza gomb, URL mező) lett. Tetszik.

Alkalmazások visszajelzése. Az alkalmazások az eddigieknél sokkal több információt tudnak visszaadni az operációs rendszernek. A folyamataikat jelezhetik a taskbar-on (bocsánat a tálcán, 40MB!), korábbi tevékenységeikről információt adhatnak vissza, jump list. (böngészési előzmények a Start Menüben, stb.)

Ez jó így, mert a célközönség intelligens, szakmaiságára büszke fejlesztőcég vagy freelancer fejlesztő. Nekik nem lehet eladni egy terméket a szépen PhotoShop-olt (vagy Paint.NET?) főképernyővel.

Pár fontos dolgot fedeztünk fel benne, áttekintve a bemutató videókkal megfűszerezetett starting kit-eket

F#. Azaz effshárp! Ismét nekifutnak, hogy nagy plénummal is megismertessék ezt a programnyelvet. Sem a lehetőségeket, sem az újdonságokat nem fogja értékelni az, aki csak WinForms vagy “adatbázisos” alkalmazásokat fejleszt. Ehhez bizony progmat és/vagy BME végzettség kell.

WorkFlow. Kezdi kinőni gyermekbetegségeit a folyamatkezelésre szakosodott keretrendszer. Ennek épp itt volt az ideje, hiszen a 4.0-s verziónál járnak.

Pararrel extension. Ehhez csak annyit kell mondanom, hogy Task<T>. Ebből mindenki tudni fogja mire gondolok. Az eddiginél is típusosabb párhuzamosság kezelést valósítottak meg. Ez valószínüleg nem egy nagy innovávió, sokkal inkább hibabiztosabb hibatűrőbb programokat eredményezhet. De csak ezért .NET 4.0-ra váltani nem érdemes.

… és a szokásos újdonságok: velocity, multi-touch gestures, surface, stb…

További információk az alábbi linkeken:

http://www.hanselman.com/blog/VisualStudio2010Beta2.aspx

http://blogs.msdn.com/somasegar/archive/2009/10/19/announcing-visual-studio-2010-and-net-fx-4-beta-2.aspx

http://geekswithblogs.net/jolson/archive/2009/10/20/visual-studio-2010-beta-2-training-kit-published.aspx

A http://www.geekzone.co.nz/paulspain/6799 bejegyzésben olvashatjuk, hogy 1000-nél több fejlesztő dolgozik az új platform kialakításán. További 65-70 betöltendő pozíció van szabadon. Ez persze nem összehasonlítható a hazai fejlesztőcégek kapacitásával, sem cégméret, sem pedig az előállítandó termék “fontosságának”, pénzügyi, iparági befolyásának tekintetében. De mégis elgondolkodtató.

1. Elképzelhető, hogy tényleg sok a munka, számos feladat vár megoldásra vagy mert nemsokára meg akarnak vele jelenni vagy mert túl sok hibát találtak és a szokásos 50-80 fős csapattal ez nem oldható meg.
2. Másik gondolatom szerint olyan mennyiségű és értékű innovációt építenek bele a termékbe (amely platform és platformra épített alkalmazások együttese), amelyet nem tesznek publikussá egy 15 fős csapat számára. Azaz mindenki csak egy kis szeletet lát belőle. Attól, hogy valaki ott fejlesztő, még nem férhet hozzá a know-how-hoz. Az Apple-lel vívott harcban ez létfontosságú.

Belső üzenőfalunkon ezt foglalta össze kollégánk:

“Gondolom egy olyan stratégiát próbálnak használni, ahol a feladatokat annyira szét osztják, hogy önmagában ne érjen semmit. Így nem tud elég sok infó kiszivárogni a termékről. És az erőforrások rendelkezésre állása is megnő, fizetni pedig az elvégzett munkáért kell. Leszűkül az üresjárati idő, ami a munkába járós, napi 8 órában foglalkoztatottaknál előfordul (Kávészünet, ebédszünet, óránként 10 perces kötelező szünet…)”

Lehet benne valami…

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

A cikk bevezetője:

“A Symbol Ügyvitel sok funkcióval rendelkező, nagy tudású, professzionális számlázó program. Alkalmas forintos- és devizás számlák kiállítására, szállítólevelek, díjbekérők (pro forma) készítésére, vevői megrendelések nyilvántartására, projektek kezelésére. A részletes terméknyilvántartás korlátlan számú eladási árat, akciót, időszaki kedvezményt, terméktulajdonság megadását támogatja. Felár ellenében árajánlat készítéssel, házipénztár- és bank modullal, valamint szerződések kezelésével is kibővíthető. A Symbol Ügyvitel könnyen telepíthető, pendrive-on is hordozható, bárhol használható, mobilis szoftver. Kezelőfelülete nem csak a lehető legkorszerűbb, hanem számtalan kényelmi funkciója miatt kifejezetten felhasználóbarát is. ”

Symbol Ügyvitel-ról szóló cikk teljes változata

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

Részletes információ: itt

Néhány érdekes témakör a konferencia sorozatból:

Cloud Computing

Simon Guest is the Senior Director of Technical Strategy in the Developer and Platform Evangelism (DPE) group at Microsoft, responsible for helping developers worldwide deliver practical and elegant solutions using Microsoft technologies. Since joining Microsoft in 2001, Simon has led the Microsoft Platform Architecture Team, acted as Editor-in-Chief of the Microsoft Architecture Journal, pioneered the area of .NET and Java 2 Enterprise Edition (J2EE) interoperability, worked with customers on mission critical .NET solutions, and has been a regular speaker at many conferences worldwide, including PDC, TechEd, and JavaOne. Before joining Microsoft, and with over 18 years in the IT industry, Simon held architect-level positions at many organizations, including Zoho Corporation, a Silicon Valley startup; Conchango, a UK based consultancy; and Herbert Smith, a leading law firm in the UK. He also worked for several years at GEC in its semiconductor manufacturing division. Simon was born in England, and has been living in the U.S. for approximately eight years. He holds a Masters Degree in IT Security from the University of Westminster, London, and a Higher National Certificate in Software Engineering from Plymouth College. Simon is the author of numerous technical articles and books about Java, Microsoft .NET, and Web technologies, as well as maintaining a blog at http://simonguest.com.

Green IT

Microsoft believes in the potential of software to drive innovations that can help address many of today’s tough environmental challenges. Find out how Microsoft products and technologies can help your organisation improve efficiency, save money, and minimise its environmental impact.

Unified Communication

Microsoft unified communications technologies use the power of software to deliver complete communications—messaging, voice, and video—across the applications and devices that people use every day. The Unified Communications track strengthens your knowledge of the Microsoft Unified Communications platform and technologies, including Microsoft® Exchange Server 2010, Microsoft® Office Communications Server 2007 R2, Microsoft Office Live Meeting and Microsoft® Exchange Online. Explore how you can streamline your organisation’s communications, build presence-aware applications, roll out an on-premise, hosted (or combination thereof) messaging and collaboration system, and much more!

Windows Embedded

Enhance your technical skills in the development and implementation of Windows® Embedded operating systems. Learn how to easily build reliable, powerful, and intelligent smart connected devices utilising our end-to-end development tools, support, and resources. Windows Embedded operating system technology has been deployed in the broadest and most demanding environments, and is at the forefront of providing a solid foundation for the next generation of 32-bit embedded devices. Windows Embedded products help you provide highly customised device designs on a flexible platform with easy-to-use development tools.

Mi ott leszünk. Legyél ott Te is, ha érdekel a témák valamelyike!

Hogy is működik?

A Delphi, mint fordítóprogram tartalmazza a fordításkor felhasznált bináris részek (ami miatt egy üres Delphi alkalmazás kb. 320kB) forráskódját is. (Ezt gyakran a programozók ki is szokták használni, például amikor az Igen/Nem kérdést feltevő ablakon nem a YES/NO feliratokat akarják látni). A vírus ezen forrásfájlok közül a SysConst.pas fájlt átírja, kibővíti, majd rögtön le is fordítja a gépen lévő Delphi-vel és .DCU állományt állít elő belőle. Bármilyen lefordított EXE, akár egy piaci termék, akár egy cég belső használatára szánt terméke tartalmazza a vírust és annak terjedéséhez minden rendelkezésre áll. Ha van a gépen Delphi.

Vesézzük ki egy kicsit, hogy is tud ténylegesen terjedni?

Valamelyik Delphi-vel foglalkozó szoftverfejlesztő cég (Magyarországon sok ilyen van) feltelepíti a konkurrens cég termékét, amely vírusos. Ezek után az ő termékei is vírusosak lesznek. Ilyen pofon egyszerű?

Mikor nem tud terjedni a vírus?

A fenti példa azonban túl speciális. Cégen belül általában a vírus terjedése meg kell, hogy álljon a fejlesztői gépeken, sőt azok között sem tud könnyen terjedni. Általában a fejlesztett programokat forrásfájlokból fordítja le egy fejlesztő. Így az EXE-k nem cserélődnek fejlesztők között. A cég többi munkatársa, akik EXE-ket kap (telepítő készlet, tesztelés, értékesítés, terméktámogatás) pedig általában nem birtokol Delphi-t a gépén.

Ahogy mi gondoljuk…

A korábban írtak szerint a terjedés egyik módja a kis szoftverfejelsztő cégek, akik egymás konkurrens termékeit a fejlesztőkkel próbáltatják ki, táptalajd adva a vírusnak. A másik terjedési mód, ha a Delphi-t gyártó cég teszi közzé a fejlesztőeszköz egy vírusos példányát. A legvalószínübb azonban, hogy valamilyen “Harmadik gyártó (3rd party)” eszközének telepítése során kerül rá a fejlesztői gépre a vírusos tool. De a terjedésnek itt is meg kellene szakadnia. Mégsem így történik.

Néhány technikai adat, félelemkeltés helyett

Szükséges Delphi verziók: D4, D5, D6 vagy D7. BDS vagy Delphi for .NET nem alkalmas erre.

Csak koncepció: A vírus kárt nem okoz, a terjedés módszerének igazolására készült.

Magyarországon csak egy: Hazákban állítólag csak egy helyen jelent meg, és mivel terjedése lassú, nem várható nagy fertőzés.

Víruskeresők már ismerik: Pár napja a víruskeresők már felismerik a kártékony kódot. Mindezt abban a pillanatban, amikor a fejlesztő az EXE-t előállítja. Pontosabban amikor nem állítja elő, mert a víruskereső karanténba zárja azt.

Microsoft .NET: A .NET-re a vírus veszélytelen, a közös kódrészletek mind az operációs rendszer részei (illetve a futtatókörnyezet részei), ilyen jellegű kódelhelyezésre nincs lehetőség.

Cégünk termékei a fenti jellemzők miatt nem tartalmazhatják a vírust

http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_ui_july

Ez csak prototípus, nem végleges, ebben a formájában még nem felhasználóbarát. De emlékeztet az MS Office hasonló célú eszköztárára. Számos felhasználó már aggályát fejezte ki, hogy “ez egy gyilkos tulajdonság”. De ha a Sun is belemegy a GUI játékba, akkor nem lehet annyira rossz az elképzelés. Mivel a funkció csak 6-os JAVA verzióval érhető el, nem tudjuk, hogy mennyire lesz a Java keretrendszer része a ribbon. Ha a Java része lesz, akkor minden Microsoft alkalmazás felkötheti a gatyáját, hiszen robbanásszerűen fognak elterjedni az ilyen Java-s alkalmazások. Már ha a felhasználók nem aggályoskodnak tovább…

Közben a Microsoft az Office 2010 termékismertetőjében már a Ribbon továbbfejlesztéséről beszélt, néhány képpel szeretnénk is bemutatni, mire is gondoltak és milyen lesz a Ribbon v2.0.

Felhasználóink már értesülhettek róla, hogy cégünk is adoptálja a v2.0-ás ribbon funkciókat és termékeink ősszel megjelenő verzióiban követjük a trendet, amit elkezdtünk: http://www.symboltech.hu/features/szalag/ 

Mindenki nagyon várja. Marketingre sokat költ a Microsoft. A fejlesztői portálok tele vannak vele, mert remek eszköz. Nem a megjelenítést szolgálja, azaz nem GUI. Mindenki használja. Mindenki meg van vele elégedve. Mindenki szidja. Mindenki mondja, hogy nem baj, a következő releaseben megoldják. Nagyon gyorsan, akár félévente jön ki belőle új release. Adatbázissal kapcsolatos. Adatbázist érünk el vele.

Igen, kitalálhattátok, hogy EntityFramework. Témánál vagyunk.

Megjelent a 4.0 béta és az alábbi bejegyzést döbbenten olvastam. Itt kell tartani egy termék 4.0-s verziójával? Ezek a nagy előrelépések a 3.0-hoz képest? A cikk itt olvasható.

Nézzük megy egy kicsit jobban, mire is gondoltam, amikor a döbbenet szót használtam. Kollégáim már tudják mire gondolok, de tudja meg más is!

• Egy ilyen készültségi szinten lévő projektben kell olyan optimalizációs lépéseket megtenni, minthogy nem hoz le minden oszlopot egy subselect, csak ami kell nekünk?
• COUNT(1) nyelvi elem direkt használata, amikor az a célszerű.
• A legnagyobb, az IN SELECT. Komolyan gondolja valaki, hogy a 4.0-ig kell várni egy kliens oldalon is jelenlévő adatstruktúra (tömb) és SQL oldalon is elérhető nyelvi konstrukció (WHERE xx IN (x,y,z…)) összekapcsolására?

Igen, emiatt van tele minden fejlesztői portál olyan jellegű kérdésekkel, hogy “Hogy tudok két táblát összekapcsolni LINQ-ban, EntityFramework-kel?” Ezek szerint nem segítség, hanem csak egy hozzászoktató eszköz, ami függőséget okoz és ha függő lettél, akkor minden fejlesztéshez a megrendelővel vetetni fogsz MsSQL Server 2010-et, supporttal, majd kell még 5 profi kolléga, aki natív SQL-hez nem ért, de kiválóan függő EntityFramework-kel.

A saját, fentihez hasonlító dolgokat megvalósító keretrendszserünk első bétája ennél sokkal több dolgot valósított meg. Mert a való életre próbáltuk alkalmazni és a tervezéskor használt use-case-ek a tapasztalatból táplálkoztak.

Sok energiát fektetünk abba, hogy minél jobban kiismerjük a rendszer újdonságait és ezeket a jövőben ki is tudjuk használni. Rendszereink kompatibilisek maradnak a korábbi Office verziókkal is, de terveink szerint számos új lehetőséget fogunk felhasználni következő programverzióinkban.

Egy nagyon jó marketing film (úgynevezett trailer) érhető el itt.

Felhasználói szintű információkat tett közzé a Microsoft az alábbi oldalon.

Sharepoint 2010 sokkal szakmaibb szemmel (úgynevezett sneak videón) az alábbi linken.

Igazán nagy kihívás lesz számunkra, hogy ezeket az eszközöket a hazai környezetbe illesszük, tekintettel az itthoni cégek finanszírozási kérdéseire és nem utolsó sorban az újdonságtól való “félelem” leküzdésére.

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.

Az alábbi linken pár információval szolgálnak arról, mik is ezek az újítások. Én csak a tálca újdonságait emelném ki. Ezidáig a felhasználót a jobb alsó sarokban lévő úgynevezett értesítési területen lehetett informáli dolgokról. Milyen folyamatok futnak, mennyi ideig tart még a DVD megírása, a fájl letöltése.

Ezt most egy kicsit megbolondították és elérhetővé tették folyamatjelzők és ikonok megjelenítését a tálcán, ahol eddig a program főablakának címe szerepelt és jobb esetben az alkalmazás ikonja (számos fejlesztő felejt el ikont adni). A lehetőségek között szerepel:

• Véges folyamatjelző
• Végtelen folyamatjelző (nem kiszámítható befejezési idővel)
• Hibajelző (piros)

És ehhez elég lesz a .Net framework 4.0?

Elég, sőt 3.5-tel is működni fog, le kell hozzá tölteni a WindowsApiCodecPack-et (4MB, súgóval együtt 19MB), amely forrásfájlokat szolgáltat számunkra, hogy a Windows7 fenti szolgáltatásait elérjük. DirectX is kell hozzá a leírás szerint, de ez valószinüleg akkor szükséges, ha a CodecPack DirectX-es szolgáltatásait is szeretnénk használni.

Lehetőségünk lesz elérni a ITaskBarList3 interfész SetOverlayIcon, SetProgressState és SetProgressValue metódusait, amivel lehetőségünk van a felhasználóinkat informálni egy hosszabb programfolyamat állapotáról.

Referenciaként a Core és Shell szerelvényeket kell a projekthez hozzáadni, ezen névterekben pedig megtalálhatóak a szükséges osztályok:

• Microsoft.WindowsAPICodePack.Shell.Taskbar
• Microsoft.WindowsAPICodePack.Shell.Taskbar.ProgressBar
• Microsoft.WindowsAPICodePack.Shell.Taskbar.OverlayIcon

Ezen kívül a ProgressBarExt és OverlayIconExt osztályok segítségével a Windows XP óta, a sok ablak megjelenítésekor összecsoportosuló programablakok mindegyike külön folyamatjelzővel látható el.

Tesztelés folyamatban…