25% áfa – számmisztika

Bruttó árkezelés tesztelése közben figyeltünk fel a következő – már-már – számmisztikai érdekességre.

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.

Öt Világ – Szoftverfejlesztés dimenziói

Joel Spolsky írása ugyan 2002-es dátumú, de még mindig tartalmaz igazságokat. Lássuk magyarul!

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/

Adathordozóinkat a szuperlemez.hu készíti

Symbol Ügyvitel termékünk adathordozóit a szuperlemez.hu készíti. Dícséret illeti őket több szempontból is!

  • 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

Tech.Ed 2009 Berlin

“Berlin felett az ég” című klasszikus film címe (rendező Wim Wanders) többször elhangzott a nemrég befejeződött berlini atlétika világbajnokság kapcsán, mivel az eső többször eleredt. Örömmel jelentjük, hogy a Microsoft Tech.Ed zárt helyen kerül megrendezésre! Berlin 2009. november 9-13.

Részletes információ: itt

tech.ed

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!

Amikor a szoftver gyártója írja és terjeszti a vírust – Win32/Induc

Egy érdekes koncepció jelent meg a vírusok egyébként is kacifántos világában. Amikor a szoftver gyártója írja, fordítja és terjeszti a vírust. Terjedési módja nem hagyományos, de be kell látni, hogy működik. A vírusok világában egyensúlyi állapot nincs. A fertőzött egyedek száma vagy nő vagy csökken. Ebben az esetben nőtt, de a terjedés módja annyira profán, hogy májusi megjelenése óta csak a héten derült rá fény.

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.

Delphi6
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.

veszelyesvirus
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

A külcsín is fontos egy ügyviteli rendszernél – MacOS skin és társai

Nagy figyelmet fordítunk arra, hogy az általunk fejlesztett ügyviteli rendszer ne csak működésében, de kinézetében is munkára ösztönző legyen, kedvet kapjon az ember a napi feladatai elvégzéséhez. Egy irodai alkalmazás nem a szórakozást szolgálja, legyen az ablakoknak sarka! De mégis varázsolhasson egy kicsit a felhasználó!

É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

 [singlepic id=7 w=640 h=480 mode=web20 float=]

“Új hullám”

[singlepic id=10 w=640 h=550 mode=web20 float=]

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

[singlepic id=6 w=640 h=550 mode=web20 float=]

Mi mindenből lehet választani…

[singlepic id=9 w=640 h=550 mode=web20 float=]

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

OpenOffice is ribbonra vált, Microsoft már a Ribbon 2.0-t készíti

Nemrég jelent meg egy hír arról, hogy az OpenOffice-t fejlesztő Sun is egy olyan műveletgombokat tartalmazó eszköztárat készít, mint évekkel ezelőtt a Microsoft.

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

OpenOffice GUI

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.

msribbon2

msribbon1

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/ 

Web2, Twitter, kövess minket Te is!

Kihasználva a Web 2.0 előnyeit, megjelentünk a Twitteren: SymbolTech on Twitter

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

twitter

Kövess minket Te is itt: SymbolTech on Twitter

Még mindig nagyon gyenge a .NET Entity Framework 4.0 béta

Találós kérdéssel indítok. Tehát mire gondoltam?

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.

PowerCommands – azaz ne hiányozzon semmi a VS2008-ból

Visual Studio 2008 remek eszköz. Számunkra egy dolog hiányzik belőle, mégpedig az, hogy a szépen, névterekben elhelyezett osztályok, ablakok, usercontrol-ok ugyanilyen szép mélységű könyvtárfát hoznak létre, amit ha egyszer kinyitottunk, sok kattintással tudjuk összecsukni.

Ettől még jól használható, pláne, ha már a VS2005-höz is létezett VB-ben írt makró, ami becsukja a fát. Ennek volt kezdetleges változata, amely csak 1-1 szintet csukott be. És volt, ami már rekurzívan is működött. A tegnapi napig…

 

collapseproject

Egy VS2008 biztonsági frissítés feltelepítése óta nem működik. Lenne erőforrásunk debugolni, de csak-csak van más megoldás is, mondjuk egy ingyenes Microsoft tool!

A szoftverfejlesztő cégek mindegyike pénzért adja a termékeit. Bizonyos “kultúrákban” a termék ingyenes, a támogatás, ami által a tényleges előnyt szerzed, viszont fizetős, lásd Apache, Linux, MySql. Ebből kiindulva nem is keresgéltünk nagy tudású, de mégis ingyenes, “5 éve fejlesztjük, nagyon jó” termékek irányába, hiszen semmi nincs ingyen.

És találtunk egy tool-t, amely megfelel a céljainknak, hivatalos Microsoft termék, ingyenes, gyakorlatilag egy extension, amelyet minden bizonnyal a Microsoft is használ saját berkein belül. Talán a létrejötte is annak köszönhető, hogy valamelyik fejlesztő majdnem fellázadt a saját eszközük ellen.

Letölthető erről az oldalról.

PowerCommands for Visual Studio 2008