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 https://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

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.

https://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: https://www.symboltech.hu/features/szalag/ 

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.

Office 2010 – felkészülés

Cégünk megkezdte az Office 2010 rendszerrel való együttműködésre való felkészülést.

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.

office2010

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.

Administrator – a kifejezés eredete

A számítástechnikában mindenki ismeri az administrator szót, sőt a sima felhasználó is biztosan találkozott már vele, mert pár kivételtől eltekintve minden számítógépes program, amely felhasználókat kezel alapértelmezetten az ADMIN felhasználót létrehozza. Kivételként említhetjük az Oracle-nél alkalmazott Scott, James, Adams, stb. felhasználókat, illetve az MsSql SA-ját, ami kifejtve szintén tartalmazza az Admin szót (SysAdmin). De honnan maga a kifejezés?

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: AdMinistrator. 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).

symboltechcard800

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.

Windows 7 tálca újdonságai – fejlesztői szemmel

Napvilágot látott (le is tölthető, meg is vásárolható lassan) a Microsoft új operációs rendszere, amely felhasználói szemmel újdonság, fejlesztői szemmel kihívás.

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)

taskbarwithprogressandoverlays

É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…