A 2880Ft-os számlázó esete Tóth Marival

Olcsó, nem szép, de legalább elég koros. És ismétlem, olcsónak tűnő. Milyen is lenne ennyi idősen?

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…

Találd meg a céget a térképen és vágd ki a monitoron található kupont

Nem, nem a Google AdWords-ös kuponokról van szó, amit boldog, boldogtalan osztogat, hanem a vállalkozásokat összefogó Google “Local” nevű kezdeményezésről. Ez eddig csak a tengerentúlon volt elérhető, de ettől a hónaptól már Európában is. És rögtön van egy monitorról kivágható kupon is.

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: https://code.google.com/intl/hu/apis/coupons/

Új számológép a Windows7-ben

Számos újítás és innováció (ami nálunk is kulcsfogalom) mellett régebbről is ismert komponensek is megváltoztak a Windows7-ben. Pár dolog, ami eddig kiderült:

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

calcexe

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

Visual Studio 2010 – lassú víz partot mos(t)

Egyre több információ jelenik meg a Visual Studio 2010-es kiadásáról. A megjelenést biztosan meg fogja előzni egy nagyobb médiakampány, de egyelőre csak blog-okon találhatóak bejegyzések és szépen lassan adagolják az információkat.

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.

vs2010

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.

vs2010splash

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

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

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

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

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

Virtuális boncolás – Mozgasd az egész asztalt a kezeddel

Virtual Autopsy. Senkit ne riasszon meg a cím magyar fordítása. Boncolást jelent, de inkább a technológia a fontos. Nagyon “kellemes” használati módja, ebben az esetben orvostudományi szempontból, a Microsoft Surface-nek. Ezen a linken lelhető róla több infó és video.

1000+ fejlesztő dolgozik a Windows Mobile 7-en

Minden eddiginél kiugróbb mennyiségű erőforrást használ fel a Microsoft az új Mobile platform kialakításához. Ezt is kell tennie, mert már sok a konkurencia.

A https://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ú.

wm7

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…

Google – ronda és finom

Két nappal ezelőtt a google nyitólapján a beviteli mező és a gomb három betűmérettel nagyobb lett. És mindez a népszerűségét növeli! Manapság, amikor már az 1024×768 dívik és 19col alatt nincs monitor/lcd/tft…

Egy érdekes, még éppen elolvasható hosszúságú bejegyzésre bukkatunk. Bevezetője is gondolatébresztő.

1998google

“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: https://numlockholmes.blog.hu/2009/07/24/title_97900

Értékesítési partnerünk az Ügyvitelbázis

A 2006-ban indult Ügyvitelbázis Magyarország egyetlen mértékadó, ügyviteli programokat értékelő portálja. A mai nappal az Ügyvitelbázis is forgalmazza termékünket, a Symbol Ügyvitelt.

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

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