web címkéhez tartozó bejegyzések

Több website-ot tartalmazó solution publikálása Azure-ra

Az Azure Websites egyik kiváló szolgáltatása, hogy közvetlenül hozzá lehet kapcsolni forráskód kezelő rendszerhez, így amikor a forráskód frissül, az automatikusan azonnal kikerülhet a felhőbe.

Ezt pofonegyszerű összevarázsolni, csak indítsuk el a New –> Compute –> Web Site –> Custom create varázslót:

multisite-new

Az első lépésben adjunk nevet a webhelynek, és pipáljuk be a Publish from source control jelölőnégyzetet:

multisite-name

Ennek hatására megjelenik a varázsló második lépése, ahol kiválaszthatjuk a forráskódkezelő rendszerünket, például GitHubot:

multisite-where

GitHub esetén egy OAuthos authentikáció következik, majd meg kell adnunk, hogy melyik repository-nak melyik ágát (már nem csak mastert lehet!) kívánjuk erre a webhelyre publikálni:

multisite-repo

A pipára kattintva meg is történik a varázslat, pár másodperc alatt létrejön a webhelyünk és már települ is rá az alkalmazás.

De mi van akkor, ha a forráskód olyan Visual Studio solutiont tartalmaz, amiben több webes projekt vagy több website van, melyik fog települni? Az első.

Azonban mi nem mindig ezt szeretnénk.

Ha az Azure website-ra mindig a solution egyik projektjét kívánjuk telepíteni, akkor létrehozhatunk a repo gyökerében egy .deployment nevű INI fájlt, amiben megadhatjuk a telepítendő projektet:

[config]
project = MySolution/MyWebProject.csproj

Előfordulhat azonban, hogy több Azure website-unk van, és az egyikre a solution egyik webes projektjét, a másikra a másik webes projektjét kívánjuk telepíteni. Ebben az esetben a beállítást nem drótozhatjuk bele a forráskódba, hanem a felhőben kell trükköznünk. Látogassunk el a CONFIGURE oldalon belül az app settings szekcióba, ahol vegyünk fel egy új beállítást Project néven:

multisite-appsettings

Az értékként adjuk meg a .csproj fájlra vagy az ASP.NET website mappájára mutató repo-gyökér relatív elérési utat.

Mentés után a következő deploymentnél már ennek figyelembe vételével fog történni a telepítés.

 

Technorati-címkék: ,,,
Reklámok

Feltöltött fájl típusának meghatározása

Nem ritka feladat, hogy egy weboldalon szeretnénk megszűrni, hogy a felhasználók milyen típusú fájlokat tölthetnek fel. Fontos, hogy a felhasználó fényképe valóban egy böngészőben megjeleníthető képfájl legyen, vagy hogy a feltöltött XLSX fájl valóban Excel fájl legyen, hiszen különben nem tudjuk belőle kiolvasni az adatokat.

Erre a problémára a klasszikus megoldás a feltöltött állomány kiterjesztésének vizsgálata. Azonban egy percre se felejtsük el, hogy a vizsgált fájlnevet és vele együtt a kiterjesztést is a HTTP kérés részeként kapja meg a weboldal, azaz pontosan annyira bízhatunk meg benne, mint a HTTP kérés bármelyik más részében. Semennyire.

Egy kicsivel jobb megoldás, ha beleolvasunk a fájlba, és megkeressük azokat a bájtokat, amik egy adott fájltípusra jellemzőek. Ezeket a bájtokat hívják “file (type) signature”-nek. Gary Kessler weboldalán elég sok ilyen signature-t összegyűjtött, sőt ott további weboldalakra, adatbázisokra, eszközökre is találhatók hivatkozások.

Számunkra most az a nagy kérdés, hogy .NET kódból hogyan valósítjuk meg ezt a legegyszerűbben. Nyilván tökéletesen működő megoldás, ha beletekerünk a fájlba a megadott offsetig, onnan kiolvassuk a szükséges számú bájtot, majd összehasonlítjuk őket a várt bájtokkal. Ez jól fog működni addig, amíg valamelyik gyártó nem változtat egy kicsit a fájl formátumon, akkor ugyanis frissítetünk kell a kódunkat.

Egy kicsit “hivatalosabb” megoldás, ha a FindMimeFromData Win32 API függvényt használjuk, amit egyébként az Internet Explorer használ MIME type sniffingre. Némi P/Invoke trükközéssel meg is hívhatjuk .NET-ből, ahogy az alábbi példa is mutatja:

using System;
using System.Runtime.InteropServices;

/// <summary>
/// Helper class to detect the MIME type based on the file header signature.
/// </summary>
public static class MimeSniffer
{
    /// <summary>
    /// Internet Explorer 9. Returns image/png and image/jpeg instead of 
///
image/x-png and image/pjpeg. /// </summary> private const uint FMFD_RETURNUPDATEDIMGMIMES = 0x20; /// <summary> /// The zero (0) value for Reserved parameters. /// </summary> private const uint RESERVED = 0; /// <summary> /// The value that is returned when the MIME type cannot be recognized. /// </summary> private const string UNKNOWN = "unknown/unknown"; /// <summary> /// The return value which indicates that the operation completed successfully. /// </summary> private const uint S_OK = 0; /// <summary> /// Determines the MIME type from the data provided. /// </summary> /// <param name="pBC">A pointer to the IBindCtx interface. Can be set to NULL.</param> /// <param name="pwzUrl">A pointer to a string value that contains the URL of the data. Can be set to NULL if <paramref name="pBuffer"/> contains the data to be sniffed.</param> /// <param name="pBuffer">A pointer to the buffer that contains the data to be sniffed. Can be set to NULL if <paramref name="pwzUrl"/> contains a valid URL.</param> /// <param name="cbSize">An unsigned long integer value that contains the size of the buffer.</param> /// <param name="pwzMimeProposed">A pointer to a string value that contains the proposed MIME type. This value is authoritative if type cannot be determined from the data. If the proposed type contains a semi-colon (;) it is removed. This parameter can be set to NULL.</param> /// <param name="dwMimeFlags">The flags which modifies the behavior of the function.</param> /// <param name="ppwzMimeOut">The address of a string value that receives the suggested MIME type.</param> /// <param name="dwReserverd">Reserved. Must be set to 0.</param> /// <returns>S_OK, E_FAIL, E_INVALIDARG or E_OUTOFMEMORY.</returns> /// <remarks> /// Read more: http://msdn.microsoft.com/en-us/library/ms775107(v=vs.85).aspx /// </remarks> [DllImport( @"urlmon.dll", CharSet = CharSet.Auto )] private extern static uint FindMimeFromData( uint pBC, [MarshalAs( UnmanagedType.LPStr )] string pwzUrl, [MarshalAs( UnmanagedType.LPArray )] byte[] pBuffer, uint cbSize, [MarshalAs( UnmanagedType.LPStr )] string pwzMimeProposed, uint dwMimeFlags, out uint ppwzMimeOut, uint dwReserverd ); /// <summary> /// Returns the MIME type for the specified file header. /// </summary> /// <param name="header">The header to examine.</param> /// <returns>The MIME type or "unknown/unknown" if the type cannot be recognized.</returns> /// <remarks> /// NOTE: This method recognizes only 26 types used by IE. /// http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx#Known_MimeTypes /// </remarks> public static string GetMime( byte[] header ) { try { uint mimetype; uint result = FindMimeFromData( 0,
null,
header,
(
uint) header.Length,
null,
FMFD_RETURNUPDATEDIMGMIMES,
out mimetype,
RESERVED );
if( result != S_OK ) { return UNKNOWN; } IntPtr mimeTypePtr = new IntPtr( mimetype ); string mime = Marshal.PtrToStringUni( mimeTypePtr ); Marshal.FreeCoTaskMem( mimeTypePtr ); return mime; } catch { return UNKNOWN; } } }

Ez a függvény megbízhatóan működik, azonban csak a 26 leggyakoribb fájltípust képes felismerni. Ami egyébként nem kevés, a fájó pont inkább az, hogy az Office formátumokat ZIP-ként ismeri fel.

Némi keresgéléssel ráakadhatunk a neten más projektekre is, például a CodePlexen található FileTypeDetective kevesebb fájl típust ismer, de pontosabban azonosítja az Office állományokat. Ráadásul a lényeget megtaláljuk a forráskódjában.

Akármelyik módszert választjuk is, ne felejtsük el, hogy bevezettünk egy külső függést a rendszerbe, ráadásul azt sem tudhatjuk, hogy mennyire időtálló a megoldásunk.

 

Technorati-címkék: ,,

Mockupkészítő eszközök

Kevés olyan hasznos dolog van a fejlesztő életében, mint a mockupkészítő eszközök. Ezek olyan szoftverek, amelyek segítségével leskiccelhetjük, hogyan fog kinézni az alkalmazásunk. Bár a mockupok tipikusan fapadosan kinéző drótváz ábrák, mégis számtalan előnyük van:

  • Legalább egyszer mi is végiggondoljuk, hogy milyen funkciókat szeretnénk, és azok hogyan fognak megjelenni a felhasználói felületen. Akár a teljes alkalmazást lerajzolhatjuk, és a hagyományos képfájlokkal ellentétben a mockupkészítő eszközök által biztosított interakcióknak köszönhetően akár ki is próbálhatjuk.
  • Az ábra felett eszmét cserélhetünk másokkal, akár a megrendelővel, akár más tervező/fejlesztő kollégákkal. Amikor mindkét fél látja, amiről beszélnek, sokkal fókuszáltabb és hatékonyabb tud lenni a megbeszélés. Ha valakinek ötlete van, azt sokkal gyorsabban át lehet vezetni egy statikus ábrán, mint egy élő kódon.
  • Az ábra mellé villámgyorsan feljegyezhetjük a legjobb ötleteinket (pl. “A Mentés működjön Ctrl+S-re is.”), ami sokkal gyorsabb, mint dokumentációt írni, arról nem is beszélve, hogy egy rövid feljegyzést sokkal valószínűbb, hogy elolvas az implementációt végző fejlesztő.
  • A mockup alapján szinte mindenki, a grafikus, a sitebuilder, a fejlesztő azonnal el tud kezdeni dolgozni és még a megrendelő is látja, hogy halad a projekt.
  • Egyes eszközök kódvázat is tudnak generálni az ábrából, ami talán még használható kiindulópont is lehet a fejlesztés során.

Összességében azt tapasztaltuk, hogy a mockupok egyértelműbbé teszik mindenki életét, és bár látszólag plusz munkát igényelnek, a félreértések megszűntetésével végül spórolhatunk velük.

Szerintem teljesen mindegy, hogy milyen eszközzel készülnek a mockupok, a lényeg, hogy a rajzolás ne igényeljen több időt, mint majd az implementáció. Ennek fényében én sokáig papíron mockupoltam, de ma már vannak egészen hatékony eszközök.

Balsamiq Mockups

A Balsamiq egy Adobe Air-re épülő, kifejezetten statikus mockup készítésére tervezett alkalmazás. A használata pofonegyszerű, talán ennek köszönhetően vált a legelterjedtebb eszközzé ezen a piacon. A Balsamiq nem ingyenes, de 79 dollárt simán megér, mi is ezt használjuk már évek óta.

Ami tetszik benne:

  • Bármilyen alkalmazást megtervezhetünk benne, legyen az desktop, webes vagy mobil app:

balsamiq-components

  • A Balsamiq már annyira elterjedt, hogy kis keresgéléssel kész template-eket találhatunk a neten, például akár Windows Phone vagy Windows 8 fejlesztéshez.
  • Ahogy a fenti ábrán is látszik, a beépített vezérlők kifejezetten rondák (bár az újabb Balsamiq verzióban már “szép” skint is lehet rájuk húzni), ami azért nagyon praktikus, mert egy megbeszélés során a dizájn nem vonja el a figyelmet a lényegről, ami mockupok esetén a funkció, a layout és a navigáció. Aki találkozott már olyan ügyféllel, aki 2-3 órát képes volt elfilózni azon, hogy egy-egy ikon mennyire felismerhető, az tudja, hogy miért preferálom a ronda mockupot.
  • Az ábrák képesek minimális interakcióra, ugyanis valamennyi vezérlő kattintható és a kattintás hatására képes elnavigálni minket egy másik oldalra. Egy popup ablakot ennek megfelelően úgy rajzolunk, hogy duplikáljuk a teljes ábrát, majd a másolatra rárajzoljuk a felugró ablakot. Ez ugyan plusz munka, de szinte mindent kipróbálhatóvá tesz.
  • A vezérlők újrafelhasználható egységekbe csomagolhatók, így például egy menüt, vagy egy master page-et elég egyszer megrajzolnunk és egy helyen karbantartanunk.
  • A Balsamiq-nak van teljes képernyős vetítő üzemmódja, ami egyeztetéseken nagyon praktikus szokott lenni.
  • Az ábrákat képes PDF dokumentumba exportálni, ráadásul úgy, hogy kattinthatóak maradnak, tehát egy sima PDF olvasóval kipróbálhatóvá válik a mockup.

Néhány tanács azoknak, akik most kezdenek a Balsamiq megismeréséhez:

  • Vásárlás előtt próbáld ki a szoftvert, van belőle trial és böngészőben futtatható próba változat is.
  • Nézd végig a vezérlőket, hiszen nincs bosszantóbb annál, mint amikor az ember megrajzol egy összetettebb UI elemet, azután pedig kiderül, hogy készen is behúzhatta volna az eszköztárról.
  • Mielőtt nagyobb rajzolásba fogsz, keress a neten kész template-eket, például a MockupsToGo oldalán jó adag található.
  • A Balsamiq használata egyszerű, hamar rá lehet érezni, mégis azt javaslom, hogy fusd végig a dokumentációt, megéri. Sőt, ha van 2 órád, végigolvasni is megéri. Az újrafelhasználható komponensek (azaz Symbols) használata talán nem teljesen magától értetődő, de arról is van doksi.
  • A gyorsbillentyűk használata sokat dobhat a tempón.
  • A fájlnevekhez már az elején találj ki egy elnevezési konvenciót. Ez azért fontos, hogy az oldalak közötti linkelés tisztán fájlnév alapján megy (nincs projekt fájl), és ha átnevezel egy fájlt a diszken, nem fognak működni a rá mutató linkek.

Honlap: http://balsamiq.com

Infragistics Indigo Studio

Az Indigo Studio egy pár hete megjelent új eszköz, ami a Balsamiq monopóliumát igyekszik megdönteni az alábbiakkal:

  • Szebb, élethűbb mockupok készíthetők vele (bár szerintem ez nem előny).
  • Képes összetettebb interakciókra és animációkra.
  • Tud Balsamiq fájlt importálni (ez mekkora ötlet ;-).
  • A V1 verzió ingyenes és az is marad, majd csak annak kell fizetni, aki a V2 verziót akarja használni. Ez egy érdekes megoldás arra, hogy egy új termék betörjön a piacra (még érdekesebb lenne, ha a letöltés egyszerűbb lenne).

Az első ismerkedéshez készítettek egy 6 részes videó sorozatot, szerintem azzal érdemes kezdeni.

Mivel futó projektjeinkben nem akarunk váltani, ezért még nem ástam bele magam az Indigo Studio használatába, de majd a következő projekt előtt megnézem. Van már vele valakinek gyakorlati tapasztalata?

Visual Studio 2012

A VS 2012 egyik rejtett szépsége, hogy beépít a PowerPointba egy Storyboarding nevű fület, amely olyan elemeket tartalmaz, amiket akár mockup rajzolásra is használhatunk. Azért “akár”, mert ahogy a neve is mutatja, itt nem kifejezetten a UI a fontos, hanem a felhasználáshoz kapcsolódó sztori.

powerpoint-storyboard-shapes

A panel alján található Find more Storyboard Shapes online link a Visual Studio Gallery Storyboard Shapes kategóriájába visz, ahonnan további rajzelemeket tölthetünk le. Ez a kategória egyelőre nem tartalmaz sok elemet, de azért vannak már használhatók, természetesen némelyik fizetős. Itt van például a Windows8Templates:

Windows8Templates-Storyboard-Shapes-Capture1

A PowerPoint óriási előnye, hogy alig kell tanulni a használatát, ráadásul minden gépen elérhető. Ha bővülne a közösségi kínálat, gyorsan nagyon használhatóvá válna.

Pár bevezető link:

 

Ti szoktatok mockupolni, és ha igen, milyen eszközt használtok mockup elkészítésére?

 

Megcélzott képernyőfelbontás

A w3schools.com szerint:

“Most computers today have a screen resolution higher than 1024×768 pixels.”

Konkrétan az ő 2012. januári statisztikájuk alapján a böngészők 85.4%-nak 1024×768-nál nagyobb a felbontása.

Néhány általunk üzemeltetett oldalon ez az arány 84-91% között mozog, de ezeknél többnyire műszaki célközönségről van szó.

Ti mostanában mekkora képernyőfelbontásra tervezitek az oldalaitokat?

 

Technorati-címkék: ,