Humor kategória bejegyzései

Ötdimenziós tárgyak nyomtatása 3D nyomtatóval

Pontosan 5 évvel ez előtt ezen a napon vált online elérhetővé a British Journal of Psychology 49. évadának 1. száma, amelyben Lionel Penrose és fia, Roger Penrose Impossible Objects címmel publikált egy cikket olyan tárgyakról, amelyek szerintük nem létezhetnek. Ezek közül talán a Penrose-háromszög a legismertebb:

5d-penrose-triangle

A cikk eredetije jóval korábban, 1958-ban jelent meg, és az azóta eltelt több, mint 50 év alatt a tudomány sokat fejlődött. Mai tudásunkkal már kijelenthetjük, hogy Penrose-ék tévedtek, ezek a tárgyak igenis létezhetnek, a modern 3D nyomtatási technológia segítségével mi magunk is létrehozhatjuk őket.

Első lépésként egy modellre lesz szükségünk, amit ki tudunk nyomtatni. Itt jön az első probléma, ugyanis a hagyományos térbeli rajzoló alkalmazások maximum három dimenzióval tudnak megbirkózni, márpedig itt nekünk többre lesz szükségünk. Azaz felejtsük is el rögtön a SketchUpot, a Blendert, az AutoCADet, a Mayat, TInkercadet stb., hiszen ezek csak 3D-ben tudnak gondolkodni.

Az egyetlen lehetséges megoldás (legalábbis én másról nem tudok), hogy a modellünket kódban írjuk le, amire szerencsére létezik már bevált, és elterjedt megoldás, az OpenSCAD. Kiváló eszköz! Aki csak egy kicsit is vonzódik a programozáshoz, annak csak ajánlani tudom, hogy így írja le a 3D modelljeit. Mivel itt kóddal dolgozunk, nem korlátoz minket a háromdimenziós tér, bátran használhatunk olyan transzformációkat, amik további dimenziókba viszik a modellünket. Amire szükségünk lesz, az a to5d() metódus, ami az OpenSCAD CheatSheeten a Transformations csoportban található:

5d-openscad

Ha így sikerült elkészíteni az ötdimenziós modellünket, jöhet is a nyomtatás, aminek első lépése az STL modell szeletelése. Én ehhez leggyakrabban Curat szoktam használni, mert számomra nagyon átlátható a felülete. Sajnos talán pont az átláthatóság miatt számos opció nincs kivezetve az alap felhasználói felületre, hanem csak az Expert config ablakban érhető el:

5d-cura-expert-config

Sőt, az ötdimenziós nyomtatás még ide sincs alapból kivezetve, de a figyelmesebb szemlélők észrevehetik, hogy míg a legtöbb szöveg egymástól függőlegesen egészséges távolságra van elhelyezve, addig a Black Magic kategóriában nagyon össze vannak zsúfolva a sorok. Ennek az az oka, hogy ha bepipáljuk az első két opciót, akkor megjelenik egy harmadik Enable more dimensions néven, pipáljuk be ezt is:

5d-cura-black-magic-settings

Ez után már nem lesz gond az OpenSCAD-ből exportált 5D STL fájl megnyitása, amit azután a szokásos módon nyomtathatunk. Íme, nekem így sikerült a Penrose-háromszög:

5d-triangle

Íme egy másik fénykép, együtt egy 3D tárggyal:

5d-triangle-with-pencil

A képet a telefonommal, vaku nélkül készítettem, az élek egyenetlensége pedig a hobbi kategóriás nyomtatóm tökéletlenségének az eredménye.

Az első “lehetetlen” tárgyam létrehozása után következő lépésként a svéd Oscar Reutersvärd kockákból felépített háromszögét nyomtattam ki, amit ő eredetileg így képzelt el (Forrás: Wikipedia):

5d-reutersvard-triangle

Ennek az OpenSCAD modellje egyébként még egyszerűbb, hiszen csak kilenc darab kockát kell létrehozni. Miután ez megvan, megnyithatjuk a modellt Curaban:

5d-cura-preview

Az előnézeti képen jobb oldalon, alulról a második kockánál látszik egy világosabb sárga rész, amit nem tudok megmagyarázni. Szerencsére csak a kép renderelése hibás, a nyomtatás simán ment, íme az eredmény:

5d-cubes

A lehetetlen objektumok kapcsán eszembe jutott M.C. Escher híres képe a végtelen lépcsőházról, ezért elkészítettem annak is a modelljét, így mutat Curaban:

5d-cura-stairs

Amint elkészül vele a nyomtató, feltöltöm a fotót.

A fenti példákból is látszik, hogy a 3D nyomtató már nem csak háromdimenziós tárgyak nyomtatására használható, ne ragadjatok le a 3D-nél!

 

Technorati-címkék:

Rejtett repülőszimulátor a Windows 8-ban

Update: Windows 7-en is működik, ha telepítve van az Internet Explorer 10!

Akik régi motorosok a szakmában, biztosan emlékeznek még rá, hogy az Excel 97-ben volt egy kissé szokatlan funkció, úgy hívták: repülőszimulátor. Ez egy olyan rejtett funkció (ún. easter egg) volt az alkalmazásban, amit csak egy ügyes lépéssorozattal lehetett előhozni, utána viszont egy 3D-s táj felett repülhettünk, ami 15 évvel ezelőtt még igen menőnek számított:

excel-97-flight-simulator

A Wikipedia Easter eggs is Microsoft products c. cikkében megtalálható még számos ilyen easter egg, megjegyezve, hogy a Microsoft a Trustworthy Computing program keretében 2002-től megszűntette az ilyen ellenőrizetlen kódokat az alkalmazásaiban.

Ehhez képest a JavaScript csapatnak köszönhetően a Windows 8-ban mégis van (legalább) egy, konkrétan az Exceles repülőszimulátornak a reinkarnációja. Állítólag eredetileg példaalkalmazásnak készült, amely a Chakra JavaScript motor képességeit lett volna hivatott bemutatni, hogy még ilyen komplex teret is képes a platform (Internet Explorer 10, Windows 8) valós időben renderelni (érdemes összevetni mindezt a Doom for Chrome-mal, amihez Native Client kellett).

A teljesítmény mellett a másik érdekesség, hogy bemutatja, milyen jól kezeli a platform a hardver szenzorokat, azaz ha tableten játszunk, akkor az eszköz mozgatásával, forgatásával tudjuk irányítani a repülőnket. Ez egyébként így 3D-ben óriási élmény, még azoknak is, akik játszottak már tableten versenyautósat.

Mivel ez az easter egg a rendszer mélyén található, nem fogjuk tudni varázs-billentyűkombinációkkal előhozni, kicsit kódolnunk kell hozzá. Másoljuk be az alábbi kódot egy szövegfájlba és mentsük el például a desktopunkra flight.js néven:

var r = "";
var e = "426F63732C206E696E637320656173746572206567672061204D6963726F736F"+
        "6674207465726D656B656B62656E2E0D0A412063696B6B20323031332E206170"+
        "72696C697320312E20616C6B616C6D61626F6C206B65737A756C74203A290D0A"+
        "687474703A2F2F62616C6173737967796F7267792E776F726470726573732E636F6D";
for ( var i = 0; i < e.length; ) {
  var l = e.charAt( i ) + e.charAt( i + 1 );
  r += String.fromCharCode( parseInt( l, 16 ) );
  i += 2;
}
WScript.Echo(r);

Majd nyissunk egy parancssort, és indítsuk el:

wscript flight.js

Íme a végeredmény:

flight-simulator-tablet

Nekem 13401 pont a rekordom, hát neked?

 

Technorati-címkék: ,

Telerik Software Craftmanship Calendar

Természetesen mi mással indulhatna az új év, mint egy új naptárral, és ha szoftverfejlesztők faláról van szó, akkor a Telerik Software Craftmanship Calendarjánál jobban nem is mutathatna más:

telerik-calendar

A naptárban minden hónapra jut valami bölcsesség, amire nem árt, ha az embert mindennap emlékeztetik, és a képesített változat talán berögzülni is segít. Mivel az e havi a Keep It Simple, bővebben itt: http://nimblepros.com/products/software-craftsmanship-2013-calendar.aspx

Köszönet Steve Smithnek a naptárért!

 

Technorati-címkék:

Hasonló ikonok

Hallottam egy kritikát, miszerint a Metros ikonokkal az az egyik probléma, hogy annyira le vannak egyszerűsítve, hogy pofátlanul lehet másolgatni őket, hiszen nagyon nehéz bizonyítani, hogy nem te rajzoltad. Ez persze megnehezíti a grafikusok életét, ami a korábbi, szinte valósághű ikonokkal sokkal kevésbé fordult elő.

Nézzük, hogy csinálják a nagyok! Íme két ikon:

Apple Gatekeeper és a Microsoft Security Essentials ikonja

Mielőtt tovább olvasnál: Szerinted csak hasonlóak vagy azonosak?

A jobb oldali a Microsoft Security Essentials (2009. szeptemberben jelent meg), a bal oldali pedig az Apple Gatekeeper (2012. február) ikonja.

És ki hagyta tárva-nyitva a hátsó kaput? Arc nagy mosollyal

 

Forrás: @Canouna

Technorati-címkék: ,

Kimaradhat a XAML a Windows 8-ból

ms-days-logoAkik esetleg követnek Facebookon vagy Twitteren már tudhatják, hogy múlt héten Dávid Zoli barátommal Szófiában voltunk.

A bolgár Microsoft múlt héten rendezte meg az MS Days 2012 konferenciát, ami egy meglehetősen komoly rendezvény fejlesztők és üzemeltetők számára. Csak hogy a méreteket érezni lehessen: két nap, 8 párhuzamos szekció, 72 előadás (melynek kb. a fele angolul), 49 előadó (akik közül sokat külföldről reptettek oda) és minderre több, mint 1000 résztvevő.

A szervezés nagyon profi volt, minden egészen flottul ment, talán csak a helyi Lurdy Ház, a Кино Арена volt egy kicsit szűkös ennyi embernek:

Кино Арена

Zolival két előadást tartottunk JavaScriptről, HTML5-ről, MVC-ről és Azure-ról, főként tapasztalatokról és legjobb gyakorlatokról. Akit érdekel, letöltheti az előadásokhoz tartozó prezentációkat és demókat innen. Büszkén jelenthetem, hogy mindkét előadás nagyon népszerű volt, sokkal többen jöttek, mint ahányan a terembe befértek, még a “falakon is lógtak”. Az értékelőlapok összesítését még nem kaptuk meg, de a Twitteren már jött néhány pozitív visszajelzés (kettőnk közül csak én vagyok Twitteren, ezért csak engem emlegetnek, de az előadásokat együtt tartottuk):

ms-bg-twitter1

ms-bg-twitter2

A második előadás után megkeresett minket a Microsoft Research két munkatársa és elmondták, hogy az egyik kiemelt projektjükben kompatibilitási problémák megoldásán dolgoznak és az előadások alapján arra gondoltak, hogy szívesen bevonnának minket is. Konkrétan azon elmélkednek, hogy a XAML egy gigantikus zsákutca, mert már sok “dialektus” van belőle (Silverlight, WPF, Windows Phone, Windows 8) és mindegyik jelentősen eltér a másiktól.

Erről egyébként bárki meggyőződhet: a CODE Magazin atyja, Markus Egger egy nagyon hasznos eszközt tett közzé a CodePlexen XAML Dialect Comparer Tool néven. Az eszköz annyit tud, hogy megadunk neki egy forrás és egy cél XAML változatot, ő pedig végigszántja a névtereket és megmondja, mennyire kompatibilisek egymással. Például ha Silverlight 5-ről Windows 8 Metro-ra akarunk átállni, akkor csak 55,19%-os kompatibilitással számolhatunk. Mindenki eldöntheti, hogy a saját esetében ez mire elég.

XamlComparer

Vissza Bulgáriához. Szóval az MSR-nél két projekten dolgoznak és mivel egy szóval sem mondták, hogy ne beszéljünk róla, elmesélem. Az egyik projekt célja, hogy XAML markupot HTML-re fordítsanak, a másiké pedig, hogy a HTML+JavaScript alkalmazásoknak 100%-osan kompatibilis környezetet biztosítsanak minden platformon. Komolyan elkezdtek azon gondolkodni, hogy a Windows 8 Metro stílusú alkalmazásoknál kínált JavaScript lehetőségek pontosan ugyanabba az irányba viszik a HTML+JS párost, mint a XAML-t: dialektikus zsákutcába. Márpedig ezt a hibát az MS nem akarja még egyszer elkövetni, így nem csoda, hogy Steven Sinofsky-t is komolyan érdeklik ezek a kutatások.

Íme egy példa! Windows 8 Metro stílusú alkalmazásban használhatunk WinJS.UI.ListView vezérlőt, így:

<div id="playeritemtemplate" data-win-control="WinJS.Binding.Template">
    <div data-win-bind="innerText:Name" style="height: 20px;" />
    <img data-win-bind="src:Photo" style="width: 200px; height: 150px;" />
</div>

<div id="PlayerListView" 
    style="height: 185px;" 
    data-win-control="WinJS.UI.ListView"     
    data-win-options="{itemRenderer:playeritemtemplate,
                       layout:{type:WinJS.UI.GridLayout,maxRows:1}}" />

Ez működik kiválóan Windows 8 esetén, de sehol máshol. Arról nem beszélve, hogy a kód elég nehezen olvasható, hiszen a WinJS.UI.ListView vezérlő hozza azt a produktivitást, ami miatt az egészet csináljuk, de fogalmunk sincs, hogy az hogyan működik. Íme egy másik példa, ezúttal egy datepicker:

<div data-win-control="WinJS.UI.DatePicker" 
     data-win-options={maxYear:2020,minYear:2000}" />

Ez is csak Windows 8-on fog bármit is produkálni, miközben dátumválasztásra mindenhol szükség van. Persze vannak tökéletes megoldások: az adatkötés megoldható például KnockoutJS-sel, a dátumválasztás pedig jQueryUI DatePickerrel. Ezek tisztán JavaScript alapú megoldások (beszéltünk is róluk az előadásunkban), tehát nincs platform probléma, feltéve persze, hogy a JavaScript futtatás nem okoz gondot az adott környezetben. Weben mindez természetes, tehát ahol webböngészőt tudunk beágyazni, ott a probléma megoldva. Nézzük sorban:

Silverlight: átfordítjuk a XAML-t HTML-re, a code behindot pedig JavaScriptre és ha a hoszt egy böngésző, akkor máris készen vagyunk. A C#-JavaScript konverzióra Nikhil Kothari Script# projektje szolgáltat megoldást. Ha out-of-browser SL alkalmazásról van szó, akkor sincs nagy gond, hiszen akkor a hoszt az explorer.exe, ami szintén beépítetten támogatja a HTML-t és a JavaScriptet (mindenki emlékszik még a böngésző beépítése körüli jogi hercehurcára). Ez egyben a SL jövője körüli kérdést is megoldja.

WPF: csakúgy mint SL-nél, itt is átfordítjuk a XAML-t HTML-re, a code behindot pedig JS-re, és mivel a hoszt itt is az explorer.exe, futni is fog vidáman. Itt már gyakrabban jöhet elő egy olyan nehézség, ami SL5-nél is, konkrétan a P/Invoke, ez ugyanis kimutat a .NET runtime adta környezetből. Erre még nincs teljeskörű megoldás, egyelőre ott tartunk, hogy aki P/Invoke-ra épít, annak valószínűleg kevésbé fontos a hordozhatóság, de ez még nem kielégítő válasz.

Windows Phone: biztos hallottátok már azt a pletykát, hogy a Windows Phone 8-nál cserélni fogják a kernelt, ami már a Windows 8-ra fog épülni. Ezt egyelőre sem megerősíteni, sem cáfolni nem tudom (ugye értitek Kacsintó arc), a mi szempontunkból csak az a lényeg, hogy ez lesz a legkevésbé fájdalommentes. Ami a Windows Phone 7-et illeti, ott szóba se jöhet egy kernel szintű módosítás, ezért valószínűleg egy runtime réteg fog bekerülni valamelyik frissítésbe, ami gyakorlatilag egy transzparens böngésző lesz a HTML alapú alkalmazások futtatására.

Windows 8: ez a legrizikósabb terület, ugyanis pont itt reklámozta az MS legjobban az új HTML lehetőségeket és most ebből kellene visszalépni a helyes útra, ami persze egy marketing öngyilkosság lenne. Bár erre bármikor lehet azt mondani, hogy eddig csak “preview” változatok láttak napvilágot, ami magában hordozta a változtatás lehetőségeit, és hogy csak az a fontos, hogy a végeredmény hosszú távon jó legyen. A Microsoft Research-ös srácokkal arról beszélgettünk, hogy Sinofsky képes lenne szembemenni a cégen belüli marketing gépezettel a profi végeredmény érdekében.

Felmerülhet persze még kérdésként a sokféle “form factor”, azaz a cél eszközök különböző mérete. Hogyan fognak megjelenni az alkalmazásaink egy kicsi telefonon vagy egy nagyobb monitor képernyőjén? Ezzel kapcsolatban szerencsére pont a Windows 8 miatt már kitalálták a megoldást, érdemes elolvasni Nacsa Sándor idevágó Standards-based adaptive layouts in Windows 8 (and IE10) című írását.

layout

Szintén érdekes problémakör az adattárolás kérdése. Itt az a szerencse, hogy a sok XAML környezet közül már a legkisebb is hozza a közös nevezőt: a Mango óta Windows Phone-on is lehet SQL Compact Editiont használni. Ha pedig külső SQL Serverre van szükség, akkor pedig maradnak a HTTP alapú REST-es API-k az adatbázis elérésére.

Mindezek a projektek gyönyörűen haladnak az MSR-nél, vannak működő megoldásaik nem csak egyszerű, hanem összetettebb alkalmazásokra is. Az igazi probléma az időzítés. Az MSR nem elég nagy ahhoz, hogy az igazi bevételt termelő Windows gépezetet visszatartsa, márpedig ha a Windows 8 megjelenik a Consumer Preview-ban található XAML és a HTML lehetőségekkel, akkor már nincs visszaút, az MS végérvényesen belezöttyen a kátyúba, ahonnan évekig nem mászhat ki (lásd VB6 és ASP támogatás Windows 8-on).

Ennek a meccsnek két eredménye lehet:

1. Marad a mostani felállás, amivel útjára indítják a Windows 8-at mint egy gigantikus kísérletet, és az esetleges problémákat, zsákutcákat majd a Windows 9-ben kijavítják. Ebben az esetben a történelem a Vista-Windows 7 párost ismételné.

2. Sinofsky a sarkára áll és azt mondja, hogy tiszta szerencse, hogy időben észbe kaptunk, szorítsuk egy kicsit háttérbe a saját érdekeinket és adjunk ki egy olyan Windows 8 verziót, ami tényleg hosszú távon jó irányba mutat, hiszen operációs rendszert nem cserélnek sűrűn sem a végfelhasználók, sem a cégek.

Sinofsky már letett valamit az asztalra, és én arra tippelek, hogy elfogadnák az érvelését, bár ez nagy érvágás lenne a Microsoftnak. Ebben az esetben ugyanis jelentősen csúszna a Windows 8 kiadása (az idén biztosan nem lenne belőle semmi), hozzá kellene igazítani az eddig elkészült alkalmazásokat, fejlesztőeszközöket, mindent. Viszont arra is nagyon jó esély van, hogy a végeredmény nagyon jó termék lenne, amivel az MS tiszteletet érdemelhetne ki, ami persze végül a bevételi oldalon is éreztetné a hatását. Így nem meglepő, hogy jelenleg ez a valószínűbb lehetőség.

De mi lesz a fejlesztőkkel ebben az esetben? A XAML halála a WPF és a Silverlight bizonytalan jövője körüli homályos információk óta egyre valószínűbb. A XAML diverzitása a saját halálát okozza, miközben lényegében semmi előnyt nem hordoz a HTML-hez képest, hiszen csak címke parszolásról van szó. Elég csak az ASP.NET MVC 4-ben lévő Razor parserre gondolni és máris tisztán látszik, hogy a HTML alapú megoldások egyszerűen jobbak. (Egyébként a Razor parser is bekerült ebbe a projektbe) Nincs értelme fenntartani egy olyan szintaktikát, ami megosztja a fejlesztői tábort, miközben van egy olyan alternatíva, ami inkább újabb fejlesztőket hozna a Windows platformra.

Ti örülnétek, ha a XAML halála miatt csúszna a Windows 8 kiadása?

 

 

UPDATE: Fontos kiegészítés a fentiekhez: http://bit.ly/xamltohtml

 

Technorati-címkék: ,,,,