Kategória: Fejlesztések
Vége a Google Reader-nek?
Igen, a Google bejelentése szerint júliusban vége ennek a szolgáltatásnak. Ez szomorú hír, de itt a lehetőség egy új szolgáltatás felépítésére! Ez a szolgáltatás pedig nem tenne mást, mint beküldött feedek tartalmát továbbítaná egy megadott email címre, ami lehet egy Gmail cím is. A Gmail szűrője és címkézési lehetőségeinek hála tulajdonképpen reprodukálható a Google Reader funkcionalitása. 😉
A szolgáltatásban az üzleti lehetőség is adott. Az emailek elejéhez és/vagy végéhez hirdetés fűzhető, aki pedig ezt le szeretné mondani, az fizessen érte néhány dollárt minden hónapban. 😛 Nos, ki vág bele a fejlesztésbe elsőként?! 🙄
Frissítés! Két hasonló szolgáltatást már találtam, de nem gondolom, hogy ne lehetne ennél a kettőnél jobbat alkotni:
(2013. március 16.)
Hozzászólás: » 3 « • Írta: Péter (2013/03/16 19:38)
Egy esetlen fejlesztő esete
Előre szólok, hogy nem szeretek senkit és semmit sem pocskondiázni, azonban ma az Across Média Kft. ügyvezetőjétől, Sasvári Gergelytől olyan válaszokat kaptam, amitől úgy érzem, hogy hülyének néznek. Ha mégsem, akkor pedig nem olvasták át elég figyelmesen a kérdéseimet, kéréseimet, de ez sem mentség, mert ez nem jelent mást számomra, mint felületes CRM-et. 🙁
Az egész helyzetről csak annyit kell tudni, hogy egy online áruház fejlesztésére kértem árajánlat, majd arra refelektálva próbáltam néhány költségtételből alkudni. Egyik költségtétel, amit sokalltam, az a havi nettó 10 000 Ft-os üzembentartási díj, amire az alábbi választ kaptam:
S. G.: “1166 Ft-ért, azaz egy Big Mac menü áráért nem találkoztam még komoly webtárhely szolgáltatással. A mi szolgáltatásunk ezért a pénzért tartalmazza a napi szintű biztonsági mentést, a szerver folyamatos karbantartását, üzemeltetését, frissítését.”
Igen, az valóban előfordulhat, hogy S. G. még nem találkozott ilyen szolgáltatással, de én találkoztam már több ilyennel is. Kedvenc példám a DotRoll Kft., ahol évi bruttó 14 000 Ft-ért non-stop támogatást és frissítést biztosítanak. A DotRollról pedig biztosan tudom, hogy mindez nem csak duma. (Innen az idézetben olvasható 1 166 Ft-os összeg.)
Ami a folyamatos karbantartást illeti, arról az a véleményem, hogy sok esetben valóban szükség van erre, amikor a megrendelői oldalon nem áll készen egy szakértői gárda, egyébként egy kiváló lehetőség ahhoz, hogy még több pénzt gomboljanak le az ügyfélről.
Pont a WebDeb vezető fejlesztőjével leveleztünk arról, hogy az elkészült áruház kódja lehetőleg legyen “önjáró”, vagyis álljon meg önállóan a lábán, és ne kelljen állandóan frissítgetni, foltozgatni azt az átadás után, hacsak nem külön igényt nyújtunk be új funkciókra. Márpedig, ha mi nem kérünk új funkciókat, és egyébként elégedettek vagyunk a szoftver működésével, akkor kérés nélkül ne nyúljanak bele a forráskódba. Az esetleges hibák javításával úgyis külön szakasz foglalkozik majd a szerződésben.
Visszatérve a levélre, amikor a kedvencek “modulra” vonatkozó válaszukat olvastam, teljesen elbizonytalanodtam afelől, hogy odafigyelnek-e egyáltalán arra, amit írok:
S. G.: “Kedvenc termékek: nem olyan egyszerű a modul, hogy ennél olcsóbban odaadjam. Az iWiW, weboldalon például csak bejelölök valakit ismerősnek egy kattintással és a háttérben lefut 10 jól megtervezett metódus. A kedvenc termékek modul körülbelül ilyen bonyolultságú …”
A kedvencek modul ára 20 000 Ft, ami alapvetően nem tűnik soknak, de én csupán annyit kértem, hogy az egyes termékeket egy kattintással hozzá lehessen adni a böngészők könyvjelzőjéhez, ahogy azt a jFav plugin is teszi. Márpedig ehhez biztosan nem kell tíz jól megtervezett metódus, amit a cikk végén be is fogok bizonyítani. Látni fogjátok, hogy ez egy fél perces site builder-i munka, azt pedig külön költségtényezőként egyszer már megemlítette a cég az árajánlatban.
Az már csak hab a tortán, amikor leírtam, hogy nem szeretnénk semmilyen extra grafikai megjelenést, hanem egy egyszerű, letisztult, kizárólag CSS-ből építkező külalakot, amire a következő válasz érkezett:
S. G.: “A webdesign tervezés a projekt lelke, rengeteg gagyi, ötlettelen weboldal található a weben. Mi ezek számát nem szeretnénk gyarapítani.”
Ezek szerint a CSS Zen Garden oldalán található megjelenések is “gagyik” … igen, bizonyos szinten ez egy szubjektív szempont, és talán a vállalat krédója meghatározza, hogy mi az és mi nem az, én szerintem a “csak CSS” nem a “gagyi” megfelelője. Na, de ennyit erről, most lássuk a jFav implementálást négy lépésben. 8)
jFav
- Töltsd le a jFav jQuery plugint!
- Csomagold ki a letöltött állományból a jFav_v1.0.js fájlt!
- A HTML kódban a jQuery melett a kicsomagolt jFav_v1.0.js-t is hivatkozd le!
- A $(this).jFav(); függvénnyel varázsolhatod a megfelelő hivatkozásokat könyvjelzővé.
Példa:
<script src="http://code.jquery.com/jquery-latest.js"></script>
<script src="./jFav_v1.0.js"></script>
<script>
$(document).ready (function () {
$('.Kedvencek').jFav ();
});
</script>
<ul>
<li><a href="http://susnya.hu/" title="Susnya Blog">Susnya Blog</a></li>
<li><a href="http://google.com/" title="Google Kereső">Google Kereső</a></li>
</ul>Aki úgy érzi, hogy ez megér neki 20 000 Ft-ot, attól kérném, hogy ezt az összeget utalja át! 😆
Hozzászólás: » 4 « • Írta: Péter (2010/09/22 17:20)
Lorem Ipsum generátor Fireworks-höz
Nem rég említettem, hogy foglalkozom drótvázak tervezésével, ezért talán az sem meglepő, hogy a közérthetőbb végeredmények érdekében szükséges a tervek szöveggel történő kitöltése. Ebben nyújt segítséget a LoremIpsum kiterjesztés, melyet erről az oldalról tölthettek le. A csomag tartalmazza a használati útmutatót, de azért lehivatkozom annak egy online változatát is.
Hozzászólás: » 0 « • Írta: Péter (2010/09/05 08:00)
Mekkora felbontásra optimalizáljunk egy webes portált?
A Blu-Ray hivatalos oldalának külseje nem olyan régen esett át egy felújításon, aminek az egyik legszembetűnőbb újdonsága, hogy nem 1 024 pixel szélességű kijelzőkre optimalizálták, hanem már az 1 280-as felbontásúakra. Jó pár éve már annak, hogy 800×600-as felbontásra kellett optimalizálni az oldalakat, ami szerintem viszonylag hamar kikopott az internetről, köszönhetően a 17″-es CRT monitorok gyors árzuhanásának és az 1 280×1 024-es felbontású LCD kijelzők megjelenésének.
Szerintem a váltás most érezhetően lassabban zajlik, ugyanis nincs a kijelzők piacán technológiai váltás, továbbá az internet és a számítástechnika akkor kezdett rohamosan népszerűsödni, amikor még az 1 024×768-as felbontású monitorokkal voltak tele a boltok. Tehát meg kell várni, amíg ezek kikopnak a használatból, ami talán már nincs is olyan messze, ha ránézünk a W3Counter globális statisztikáira.
Ha végzünk pár összeadást a táblázatban szereplő értékekkel, akkor hamar láthatóvá válik, hogy az internetezőknek körülbelül 53.30%-a szélesebb kijelzővel rendelkezik, mint 1 024 pixel, és durván 28.34%-a rendelkezik 1 024 pixel vagy annál kisebb szélességű kijelzővel. Két évvel ezelőtt még szinte pont fordított volt a helyzet.
Visszatérve a Blu-Ray oldalához, feltételezem, hogy a portál üzemeltetői annak sajátos célközönsége miatt merte bevállalni ezt az újítást, hiszen akik nagyfelbontású tartalmakat keresnek, azok jelentős többsége (köztük én is) valószínűleg nagyfelbontású megjelenítőkkel böngészi a blu-ray.com oldalait.
Természetesen egy közönséges hírportálnak biztosan nem javasolnám ezt, de már eljött az idő, amikor érdemes jobban szemügyre venni saját portálunk statisztikáit, és adott esetben nyitni a nagyobb felbontás felé. Azonban fontosnak tartom, hogy ne azt figyeljük, hogy mekkora felbontású megjelenítővel rendelkeznek látogatóink, hanem inkább azt, hogy a böngészőjüket mekkora felbontásban futtatják. Én ugyanis hiába rendelkezek FullHD felbontású kijelzővel, a böngészőmet szigorúan 1 024×768-as méretben használom. Egyrészt azért, mert a legtöbb oldal ekkora felbontásra lett optimalizálva, másrészt pedig azért, mert így mellette több másik alkalmazásnak is jut hely, melyekben a folyamatokat anélkül tudom követni, hogy váltogatnék az ablakok között. Sorolhatnám még az előnyöket, de szerintem Ti is nagyon jól tudjátok, hogy mik lehetnek azok.
Hozzászólás: » 2 « • Írta: Péter (2010/08/30 08:00)
Webes prototípus tervezés
Amióta az eszemet tudom egy honlap kódolása előtt mindig készítettem papíron vagy grafikus módon egy drótvázat, és ebből következően a specifikációk mellé minden alkalommal csatolok wireframe terveket. Nem is gondoltam volna, hogy “Magyarországon nincs igazán kultúrája, gyakran kifelejtik a munkafolyamatból (vagy nem veszik elég komolyan).”, ahogy azt Dunder Krisztián írta egyik cikkében.
Mivel csak webes felületek tervezésével foglalkozom, engem tökéletesen kiszolgál az Adobe Fireworks. Egyszerűen, gyorsan és kényelmesen tudok vele impresszív terveket készíteni, mint amilyen például a következő:
A napokban mégis úgy döntöttem, hogy kipróbálok más prototípus tervező eszközöket. A választásom elsőként a Mozilla által vezetett Pencil Project-re esett. 
A program telepíthető Firefox kiterjesztésként és önálló asztali alkalmazásként is. Rövid használat után be kellett látnom, hogy nem egy rossz eszköz. Bár nagyon intuitív és hamar elsajátítható az UI használata, az egyes paraméterek finomhangolása számomra kényelmetlen. Sokkal többet kell kattintanom az éppen szükséges opciók eléréshez, mint a Fireworks-ben, így több időt is vett igénybe ugyanazon vázlat elkészítése, ami ráadásul kevésbé volt impresszív. Ezen kívül még hiányoltam belőle a layerek csoportosíthatóságát és összevonhatóságát, illetve egy panelt, ahol nyomon követhetem azt, hogy az egyes layerek mely szinten helyezkednek el. Viszont amellett, hogy kevésbé memóriaigényes, egyik nagy előnye, hogy a hivatkozásokkal kapcsolatot lehet teremteni az oldaltervek között.
További ingyenes wireframe-tervezők után kutatva találtam rá a Cacoo online csoportmunkát is támogató webalkalmazásra, ami gyors, egyszerű, és első ránézésre szinte mindent tud, amit az előbb említett Pencil. Például érzésre sokkal kényelmesebben igazítja az egyes formákat a lap hálójára, továbbá az egyes elemek beállításai is kevesebb kattintással érhetőek el. Szerintem a Cacoo-t még sokat fogom használni a jövőben!
Hozzászólás: » 1 « • Írta: Péter (2010/08/29 12:43)
PHP: post_max_size vs. upload_max_filesize
Szerintem minden fejlesztőnek vannak sajátos számítógép-használati szokásai, így nekem is. Az egyik ilyen, hogy sokszor egy egyszerű webes űrlapon keresztül, közvetlenül töltök fel és küldök haza fájlokat a saját asztali számítógépemre. (Ez egy PHP szkript segítségével egyébként rettentő egyszerűen megoldható, de ezt most nem célom taglalni.)
A múlt héten történt, amikor a szomszéd szobában található számítógépről szerettem volna magamnak pár lapolvasóval készült képeket átküldeni, de nem sikerült, ráadásul hibaüzeneteket sem kaptam. Rögtön eszembe jutott, hogy a rendszerem legutóbbi újratelepítésekor nem módosítottam a upload_max_filesize paramétert a php.ini-ben, ezért rögtön kibővítettem a korlátot. Sajnos ezek után sem érkeztek meg hozzám a fájlok, és továbbra sem kaptam hibaüzenetet. Rövid tanácstalanság után eszembe jutott, hogy a post_max_size paramétert sem állítottam még át, amiről tudniillik azt, hogy szigorúbb kritérium, mint az upload_max_filesize. Tehát hiába lazítunk a feltölthető fájlok méretét korlátozó paraméteren, ha a teljes űrlap adatmennyiségének korlátját nem igazítjuk hozzá.
Ezt a bejegyzést egyébként azért jegyeztem fel magamnak, hogy legközelebb egyből eszembe jusson ezeket a beállításokat elvégezni az asztali rendszerem újratelepítésekor.
Hozzászólás: » 0 « • Írta: Péter (2010/08/15 13:02)
Végre elkészült a saját CSS-es RSS ikonom
Nem olyan régen a “Hétvégi CSS barkácsolás.” című bejegyzésemben próbáltam CSS segítségével kirajzolni egy RSS ikont, de első nekifutásra nem sikerült. 😮 Az elmúlt hetekben teljesen véletlenül találtam rá Zander Martineau blogjára (Rather Splendid: Pure CSS Icons), aki szintén egy RSS ikont szeretett volna léterhozni pusztán CSS és HTML kódokból építkezve. Az ő kódjainak segítségével alakítottam ki a saját gombomat, melynek eredményét lentebb már ti is áttanulmányozhatjátok. Fontos különbség a kódjaink között, hogy amíg Zander Martineau a “könnyebben” skálázható em mértékegységgel dolgozott, addig én px-t használtam.
Hozzászólás: » 4 « • Írta: Péter (2010/05/21 21:05)
Így néz ki egy up-to-date menü
A mai napon megmutatom, hogyan érdemes up-to-date, kereső- és felhasználóbarát menüket kódolni. Ezt a cikket főleg Tamás barátom kérésre írtam, mert már régebben megígértem neki, de kötelező elfoglaltságaim miatt egészen idáig nem volt rá időm. 🙁
Bővebben …
Hozzászólás: » 2 « • Írta: Péter (2010/05/17 18:47)
MTV Tudásportál
Talán még nem késő bejelentenem, de II. helyezést értem el a Magyar Televízió és a Budapesti Corvinus Egyetem E-Business Kutatóközpontja által közösen meghírdetett pályázaton. (A szemfülesek még a Híradóban is láthattak bennünket.) A dobogósok jutalma (így az enyém is), hogy részt vehetnek egy oktatási tudásportál megtervezésében és megvalósításában. A következő hónapokban izgalmas projektmunkának nézek elébe a csapattal, melynek publikus és emlékezetes mérföldköveiről itt a Susnya Blogban is meg fogok emlékezni.
Bővebben …
Hozzászólás: » 4 « • Írta: Péter (2010/03/12 10:47)
Hétvégi CSS barkácsolás
Végre volt időm elmerülni a CSS 3 újdonságaiban, és rögtön jöttek az ötletek, hogy mi mindent lenne érdemes megpróbálni kirajzolni az új szabvány adta eszközökkel, kizárólag HTML és CSS kódok használatával. 😛 Az egyik ötlet egy RSS gomb volt, amiből első nekifutásra az alábbi eredményt sikerült kihoznom:
A kódokat most nem illesztettem be ide, de ti is elérhetitek azokat ezzel a hivatkozással.
