В суботу 20 березня відбулась вже 7 за рахунком зустріч стартаперів Львова – Lviv Startup Club Session 7.0. Можна констатувати, що конференція розвивається, а рівень її організації, стартапів що представляються та учасників постійно зростає. Львів входить до списку 30 міст світу з найбільшим потенціалом розвитку інформаційних технологій, і конференція Lviv Startup Club Session доводить це.

Конференція проходила у конференц-залі бізнес-центру “Оптима-плаза” з красивим краєвидом на Львів з вікон. Тема конференції – маркетинг і реклама – була цікавою багатьом, і зібрала близько 100 чоловік, причому не лише львів’ян, але і гостей Львова.

Розклад конференції переповідати не буду – про це можна прочитати на офіційному сайті конференції. Поділюсь лише тим, що особливо сподобалось.

Виступ Ростислава Чайки про 7 маркетингових ходів особливо сподобався систематизованістю викладення. Окремої похвали заслуговує доповідь Дмитра Шоломка, представника Google в Україні, в доповіді можна було дізнатись масу цікавих цифр та фактів щодо інтернету в цілому та розвитку його в Україні. Зокрема Дмитро запевнив усіх, що Україна для Google стратегічно важлива країна, адже ми на 10 місці в європі по кількості інтернет-користувачів, а потенційно можемо бути і вище (інтернет у нас лише розвивається). Наведу кілька цікавих фактів від Google, що прозвучали на Lviv Startup Club Session 7.0:

• Проникнення інтернету по великих містах України – 50% (у великій мірі за рахунок столиці: у Києві – 70%)
• 70% молоді України користується інтернетом (тобто інтернет-аудиторія лише зростатиме з часом)
• 7% бюджету світового ринку реклами приходиться на інтернет (2007)
• За прогнозами Google у 2050 році всі 100% будуть приходитись на онлайн рекламу
• Час, який проводять люди: 37% – ТБ, 22% – радіо, 12% – читання газет та журналів, 24% – інтернет! (Європа, 2007 – можна порівнювати з Україною сьогодні)
• 67% пошуків відбуваються під впливом офлайн реклами (компанія, продукт/послуга, гасла під впливом реклами)
• 69% перед купівлею продукту шукають інформацію в інтернеті
• 81% відвідувачів сайтів попадають на них з пошуку

Дуже сподобалась панельна дискусія експертів, у якій Ярослав Максимович, Максим Залевський та Руслан Савчишин розповідали про маркетингові ходи та помилки в маркетингу. Далі були представлені 3 стартапи (див. офіційний сайт). Доречі, час не стоїть на місці, і приходять зміни і в житті учасників конференції. Зокрема, з часу LSC Session 3.0 Ярослав Максимович продав auction.ua, і тепер повністю присвятив себе баннерній мережі banner.ua

Ну і наостанок цікаві думки, винесені мною з конференції:

• Google НЕ ПРОТИ SEO: ефективність переходів на сайт зростає, якщо він є і у пошуковій видачі і у пошуковій (контекстній) рекламі при пошуку
• Контекстна реклама у пошуку є чи не найефективнішою рекламою, адже прямо відповідає на запити користувачів
• Найефективніше, коли реклама розповсюджується одночасно кількома каналами (наприклад спочатку бачемо рекламу по ТБ чи радіо, а потім на баннері чи контексті в інтернеті)
• Контектна реклама ефективна тоді, коли попит вже сформований (люди знають, що вони хочуть), а коли попит потрібно сформувати – тоді ефективніша баннерна реклама!
• Помилка вкладати купу грошей в розробку продукту (сайту) і не вкладувати в маркетинг (рекламу, SEO тощо)
• Помилка запускати дорогу рекламну кампанію сайту, коли на ньому навіть телефону немає
• Потрібно інвестувати в людей а не в продукт (бізнес – це люди, а не гроші)
• Важливо відслідковувати ефективність рекламних кампаній – лише в інтернеті це можливо. Гарні інструменти для цього – Google Analytics та Web Log Analyzer (останній платний)
• Для відслідковування згадування в інтернеті потрібних ключових слів є чудовий сервіс – Google Alerts
• Ще один сервіс від Google, що дозволяє дивитись статистику по пошукових фразах – Google Insights

Я на початку говорив про Львів як про місто з великими перспективами в галузі IT. Хто зна, можливо колись саме з Lviv Startup Club виростуть відомі на весь світ стартапи, і ми як учасники конференції будем розповідати, як стояли біля початків цього руху у Львові.

Щоб не заплутатись, розділю усі події у три групи. Про всяк випадок зазначу, що у статті приводиться особиста думка автора, яка не претендує на об’єктивність. Ну що ж, почнемо.

Події 2009 року в Україні та світі

• Світова фінансова криза
• Барак Обама став першим в історії США чорношкірим президентом
• Помер король поп-музики Майкл Джексон
• Донецький Шахтар здобув кубок УЄФА
• Початок(?) передвиборної кампанії (стосовно важливості цього пункту виникають сумніви, оскільки нам, українцям, вже не звикати)
• Пандемія свинячого грипу A/H1N1 та #panika спричинена цим явищем
• УЄФА остаточно затвердила 4 українських міста, що прийматимуть Євро 2012
• Негода в Європі та Україні

Щодо останнього пункту, хотілось би процитувати слова Сергія Петренка в Твіттері, як приклад позитивного ставлення до життя:

gray_ru Ура, снег идет.
golubovsky и это из Одессы, где все завалено снегом?!! ))) Да вы сплошной позитив!
gray_ru ну завалено, но ведь зима.

На цій позитивній ноті перейдемо до наступної групи подій.

Інтернет-підсумки 2009 року за версією Романа Голубовського

• Сайт 2009 року, відкриття 2009 року, спільнота 2009 року – Twitter.com (Follow Me – @golubovsky)
• Український блог року – WebStream (проект відкрився влітку, і, нажаль, закрився у грудні, – зате горів дуже навіть яскраво)
• Інтернет-обличчя 2009 року – Максим Спірідонов (Максим, продовжуйте у тому ж дусі!)
• Подкаст року – Рунетологія
• За вклад у розвиток УАнету хотілось би відзначити таких людей як Ярослав Федорак, Максон Пуговський, Артур Оруджалієв, Ярослав Ажнюк, Тарас Амброз та Ростислав Чайка

2009 рік для мене це

• Маса цікавих проектів по проектуванню та розробці веб-сайтів (PHP, MySQL, HTML, CSS)
• Розширення поля діяльності та новий для мене досвід роботи в SEO, SMO/SMM та інтернет-маркетингу
• Публікація деяких статтей у блозі, що привернули до себе особливу увагу. Це стаття про хамство по email, про зміну правил реєстрації доменів в зоні org.ua, про збір ручок parker, про юзабіліті карток поповнень, про клієнтоорієнтованість для клієнта тощо
• Конференції Lviv StartUp Club Session
• Подорожі до Криму (мис Тарханкут, Євпаторія – “Студреспубліка”) та до Хургади, Єгипет
• Дайвінг, поїздки на велосипеді, біг, заняття бальними танцями
• Масштабні танцювальні івенти: виступи Armin Van Buuren і Tiesto у Києві та Blank & Jones у Львові
• Курси водіїв та отримання водійських прав
• Придбання iPod – час в дорозі проходить не даремно: аудіокниги, подкасти (див. вище Рунетологія)
• Фільми Трансформери 2, 2012, Avatar
• Катя (дякую тобі за надхнення!)

Ось таким я побачив 2009 рік. А чим він запам’ятався вам? Буду вдячний за відповіді в коментарях.

P.S.: Якщо ви блогер, і написали подібну статтю у своєму блозі, – залишайте посилання на неї в коментрях або висилайте мені на пошту (roman_golubovsky ет ukr.net), – опублікую посилання на цій сторінці.

2009 рік очима інших блогерів

• Блог Юрка Червоного
• Життя в місті Рівне
• Andr1y’s Blog
• G3Ds blog
• mr.Petruccio
• Hellveen official blog
• Mixa-Blog
• Blogoreader
• Sidirom’s Blog
• Ribel’s Blog

Основна тема зустрічі – “Партнерство у стартапі“. Програму заходу переказувати не буду – її можна переглянути на сайті StartUp Club-у Львова.

Що сподобалось та не сподобалось на Lviv StartUp Club Session 3.0

Сподобалась загальна приємна атмосфера зустрічі та цікаві люди, виступи експертів та живе обговорення виступів.

Фото Ростислава Чайки

Особливо сподобався виступ Ярослава Максимовича – власника auction.ua. Фактично, це був єдиний загальновідомий успішний стартап на зустрічі. Надзвичайно цікаво було почути, що називається з перших рук, про досвід у його створенні, спілкуванні з інвесторами (DST – хто знає, той зрозуміє, який це рівень) а також про методи реклами/розкрутки проекту.

Також цікавими виявились поради Руслана Савчишина (MagneticOne) щодо пошуку синергії з партнером та Андрія Павліва (N-iX) про екстремальні способи перевірки потенційного партнера та згуртування вже існуючого колективу. Ростислав Чайка, організатор зустрічі, особливо сподобався як ведучий заходу – організацією виступів та вмінням грамотно керувати процесом обговорення (запитання та зауваження).

Ну і трошки про недоліки. Стартапери, все-таки, люди технічні, і перед аудиторією виступати не звикли. Тому презентування стартапів (у другій частині зустрічі) було не найкраще – відчувалась недостатня підготовленість та відсутність досвіду публічних виступів. Порада стартаперам – більше часу присвятіть підготовці до виступу: складіть чітку схему виступу, продумайте відповіді на запитання, які можуть виникнути в процесі виступу, потренуйтесь виступати спочатку перед друзями, – словом, готуйтесь ретельніше до виступу, – від цього виграють всі! Набагато цікавіше та живіше було обговорення стартапів та зауваження ради експертів.

Про зауваження ради експертів хотілось би сказати окремо. Рідко мені зустрічались настільки конкретні зауваження та поради. Все було дуже чітко: “Зроби то-то і то-то; тут не вистачає цього і цього”. Тобто, якщо у вас є свій стартап – не полінуйтесь, гарно підготуйтесь (! див. попередній абзац) і обов’язково представляйте його на одній з наступних зустрічей Lviv StartUp Club-у. Гарантую, що ви отримаєте масу чітких порад по покращенню, дізнаєтесь багато нового про свій проект та побачите його з інших сторін.

На майбутнє.
Щодо майбутніх зустрічей, то хотілось би побільше відомих людей та відомих стартапів (хоча це і проблематично, зважаючи на недостатню кількість таких на Українському ринку).

Як резюме, озвучу кілька цікавих ідей, які були озвучені на зустрічі:

• Коли ви вирішили робити свій стартап, перш ніж щось робити (програмувати), потрібно зробити ретельне дослідження того, чи не зроблено це раніше, і чи взагалі це потрібно; подивитись на проект зі сторони його користувача і відповісти собі на питання “чи користувався б я таким проектом?”; зробити SWOT-аналіз. Хоча це, здавалось би, логічно і не потребує додаткових доказів, людям зазвичай притаманно спочатку робити, а вже потім думати.
• Більше планування! Якщо ви все ж вирішили братись за справу, знову ж таки не починайте відразу робити, – спочатку потрібно повністю спланувати проект до дрібниць: як повинна виглядати і працювати кожна деталь у проекті. Це збереже масу часу при розробці.
• Ще до закінчення розробки починайте тестування на реальних клієнтах (у цьому випадку це не клієнти що приносять гроші, а партнери, що допомагають розвивати проект – не беріть з них грошей!) – для того, щоб не пізно було виправити концептуально неправильні речі або добавити необхідну функціональність.

Це щодо стартапів взагалі. А тепер кілька тезисів щодо основної тематики, якій була присвячена зустріч – “партнерство у стартапі“:

• Партнерів варто шукати зі схожими (в ідеалі такими ж) цілями, що і у вас
• У партнери варто брати людей, яких ви бачите не вперше. Наприклад, колишній однокласник, одногрупник чи колега по роботі. В такому разі менша ймовірність неприємних сюрпризів
• Варто перевірити потенційних партнерів в екстремальних умовах (похід у гори, дайвінг тощо)

Ну і на останок хочу подякувати усім вже згадуваним експертам та особисто Ростиславу Чайці за гарну організацію заходу. Наступним зустрічам Lviv StartUp Club бути!

Додаткові матеріали:
Сайт Lviv StartUp Club
Lviv StartUp Club В Твіттері
Фото зустрічі можна переглянути тут.

Клієнтоорієнтованість або орієнтація на клієнта – стратегія ведення бізнесу компанії, у відповідності з якою вона (компанія) робить дії (подекуди зовсім нестандартні та індивідуальні), спрямовані на задоволення потреб клієнта, з метою перетворити його в лояльного клієнта.

- це своїми словами. А тепер приведу визначення клієнтоорієнованості (на російській мові) Ігоря Манна, одного з найвідоміших російських маркетологів (чи точніше маркетерів):

Клиентоориентированность (v2.0) – это инициация положительных эмоций и восторга у существующих клиентов, что ведет к повторным покупкам и получению новых клиентов за счет рекомендаций существующих клиентов.

Така стратегія у більшості випадків вигідна у довгостроковій перспективі, хоча деколи досить витратна в ресурсах. Для того, щоб бути клієнтоорієнтованою компанією, потрібно перш за все знати потреби своїх клієнтів. Саме для цього створюються гарячі телефонні лінії (Янукович – “почую кожного”) або цілі call-центри (МТС чи Київстар), а також технічна підтримка (суппорт). Останніми віяннями в цій області є блоги та мікроблоги (Twitter-аккаунти) компанії. Хоча, клієнтоорієнтованість не обмежується лише технологіями зворотнього зв’язку.

І якщо вже зараз стало модним для компанії бути орієнтованою на клієнта, то чому б нам, клієнтам компанії, не дати можливостей цю клієнтоорієнтованість продемонструвати! Клієнтоорієнтованістю треба користуватись – саме для цього і написана дана стаття.

Для прикладу, якщо у вас є певні побажання до певного продукту, то чому б не сказати про це його виробникам. Особливо тепер, – з допомогою Інтернету, – це зробити зовсім не важко. Ваші побажання або поради можуть бути корисні, що приведе до покращення продукту, від чого виграєте і ви, як споживач, і компанія-виробник.

Зразу застерерігаю: я не закликаю зловживати добротою компаній. Говорити про клієнтоорієнтованість можна лише якщо і сам клієнт є певним чином лояльним до компанії – лише у такому випадку від співпраці клієнта і компанії буде користь їм обом!

За прикладом того, як робити не можна, довго ходити не треба. Думаю, всім відомо про те, які люди і з якими питаннями дзвонять у call-центри мобільних операторів (таких як МТС, Київстар etc.) За ще один приклад може слугувати випадок, показаний у популярному відео, в якому російські туристи принижують працівників турецького готелю (відео можна подивитись тут). Ці випадки мають дуже мало спільного з клієнтоорієнованістю.

А щоб показати те, до чого закликаю я, найкраще буде продемонструвати приклад використання клієнтоорієнтованості з реального життя.

Кілька моїх сайтів розміщені на хостінгу UnixHost – поки досить молодий, і можливо саме через це доступний в плані ціни хостінг. Раніше, коли виникали якісь питання по роботі хостінгу, технічна підтримка зазвичай якісно і вчасно відповідала на них. От і у випадку, про який я хочу розповісти не сталось нічого виняткового. А сталось наступне.

Підійшов час оплати послуг хостінга. А в силу певних причин (відсутність доступу до робочого місця у зв’язку з хворобою) я не міг провести платіж. Тому, коли строки оплати пройшли, мої сайти заблокували. Треба було щось робити. Тоді я зв’язався з підтримкою хостінга і пояснивши їм ситуацію (увага!) попросив перенести оплату на кілька днів. І як ви думаєте, що сталось? Вони погодились! Мої сайти зразу ж розблокували, а я, в свою чергу, як і обіцяв, сплатив послуги хостінга зразу, як тільки зміг.

От приклад клієнтоорієнтованості – у виконанні хостінгу UnixHost (реф.).

З даного прикладу видно, що при застосуванні клієнтоорієнтованості виграють дві сторони – компанія (зберегла клієнта та ще й отримала рекламу у вигляді цієї статті) та клієнт (я досяг того, до чого прагнув – мої сайти працювали не зважаючи на те що я не встиг заплатити за хостінг).

Тому, якщо ви представник компанії, робіть свою компанію клієнтоорієнтованою, а якщо клієнт – допомагайте компаніям проявити свою клієнтоорієнтованість. Від цього виграє кожен!

Малюнок взято з ain.ua

Хто раптом не знає, домен у зоні org.ua можна зареєструвати абсолютно безкоштовно (володіючи, щоправда, певними технічними навиками та знаннями). Більше того, реєстрація проходить повністю автоматично, тобто заявку на створення та делегування доменного імені у цій доменній зоні ніхто з людей не перевіряє.

Така політика призвела до того, що ця доменна зона здобула недобру славу. А все тому, що реєструвати домени у цій зоні почали не лише в хороших цілях, – під такими я маю на увазі створення повноцінного, корисного для людей веб-сайту, – але і для створення так званих г**носайтів. Це сайти з не завжди унікальним і не дуже якісним контентом, що створюються виключно для заробітку грошей, наприклад методом продажу посилань з цих сайтів.

Для того, щоб створити такий г**носайт ні грошових витрат, ні великої роботи не потрібно: реєструється домен в бекзоштовній зоні org.ua, прив’язується до сайту на безкоштовній системі для свторення та безкоштовного хостінгу сайтів Ucoz (як приклад), після чого наповнюється вже згадуваним неякісним контентом, заганяється в пошукові системи і підключається до якоїсь системи продажу посилань.

Після виконання перечислених дій в Уанеті стає на один непотрібний сайт більше. І все би нічого, якби девіз офіційного адміністратора доменів в зоні UA – Хостмастера – не звучав так утопічно:

.UA – наш дiм. Зробимо його кращим!

Так от, останнім часом дехто, хто намагався зареєструвати домен у зоні org.ua зіштовхнувся з відмовою:

…

** Error: Ця реєстрація заблокована.

——–[ Технічна перевірка ]——–

– Не встановлена технічна правильність заявки

——– [ЗАЯВКА ВІДХИЛЕНА] ——–

– Помилок: 1

…

У чому ж причина відмови?

А причина відмови якраз і полягає у боротьбі з тою-таки реєстрацією доменів у нехороших цілях, про яку ми тут говоримо. Все пояснює лист-відповідь від адміністратора доменної зони org.ua, викладений на одному з інтернет-форумів:

Шановний реєстранте!

Цей текст – наперед підготовлена відповідь на типове запитання.

Ви отримали у відповідь на спробу реєстрації домена повідомлення про помилку “Ця реєстрація заблокована”. Ця помилка означає, що сервери імен використані в заявці на делегування чи зміну даних домену заблоковані. Як правило повністю внесені до чорного списку заборонених серверів або ж обмежені в кількості можливих реєстрацій на добу.

До такого блокування серверів призводить велика кількість реєстрацій на ці сервери імен доменів, що порушують правила реєстрації в публічному домені org.ua (найчастіше: порноресурси та масована реєстрація доменів для “лінкопомийок” та інших технологій спаму та обману пошукових систем) в поєднанні із затятістю порушників, які ігнорували заборони, сподіваючись що повна автоматизованість реєстрацій дозволить їм “перебороти” заборону.

Інколи такі сервери імен знаходяться під контролем недобросовісного реєстранта або ж належать невеликому хостеру і іншими реєстрантами доменів майже не використовуються. Але останнім часом масовані недобросовісні реєстрації стали використовувати популярні сервіси надання безкоштовних серверів імен чи сервери популярних безкоштовних хостерів.

Частим другим запитанням реєстрантів в цій ситуації є прохання повідомити повний список заблокованих серверів імен з тим, щоб можна було обрати хостинг, який не потрапив до цього списку. Але активність порушників правил настільки висока, що навіть існування такого списку на дасть Вам гарантії, що щойно обрані Вами сервери не доведеться обмежити в реєстраціях.

От, виявляється, у чому справа! Хостмастер впровадив нову політику щодо реєстрації org.ua. Фактично, тепер можна прив’язати домен у зоні org.ua лише до name-серверів купленого хостінгу. Тобто, безкоштовна реєстрація домену в зоні org.ua не така вже й безкоштовна – треба оплатити принаймні хостинг. Тепер молодий СЕОшник-початківець без грошей навряд зможе створити вищезгаданий га**осайт для того, щоб заробити на ньому кілька гривень.

Можливо, тепер наш дім .UA таки стане трішечки кращим!

Так вже склалось, що найчастіше (принаймні у нас) динамічні веб-сайти розробляються на зв’язці популярних технологій PHP/MySQL (блог, який ви зараз читаєте – не виключення). Саме тому, коли потрібно розробити веб-сервіс, що потребує використання бази даних, якось навіть не задумуєшся, яка саме СКБД повинна бути, а по-інерції розробляєш на вже звичній MySQL. І коли веб-сервіс майже готовий, раптом виявляється, що замовникам не підходить MySQL (та і будь-яка інша зовнішня БД) з приводу безпеки, а потрібно щоб база даних зберігалась у файлах там же, де і решта скриптів веб-сервісу. Після обмірковування можливостей око замовників падає на SQLite. І ось у мене нове завдання – зробити так, щоб вже готовий веб-сервіс з БД на базі MySQL запрацював з SQLite.

Якби у мене було трошки менше досвіду, це рішення завдало б мені чимало клопотів та нової мороки. Але, на щастя, я знаю що таке архітектура MVC (Model View Controller), і практикую її при побудові веб-аплікацій. Саме тому з задачею зміни бази даних для проекту я справився досить швидко, отримавши при цьому новий досвід. Весь процес обмежився вивченням SQLite під PHP та зміни класу, що взаємодіє з базою даних.

Тепер розповім про саму БД SQLite

SQLite – це бібліотека, що підтримує більшість специфікацій SQL92. SQLite зберігає дані в єдиному файлі – у цьому її особливість. Бібліотека є маленькою та швидкою. На відміну від інших БД, що підтримуються PHP, при керуванні SQLite не створюється окремого процесу сервера – php-програма і є сервером. Це значить, що одночасні запроси повинні блокувати файл для безпечної зміни БД. Це дуже важливо, адже стосується сфери використання SQLite – при одночасному считуванні даних немає жодних проблем, але при великій кількості одночасних оновлень в БД, програма буде витрачати більше часу на синхронізацію блокування файлів ніж робити корисну роботу.

Можливості SQLite:
- Підтримка більшої частини стандарту SQL92, включаючи тригери і транзакції
- Підтримується БД до 2 терабайт
- Відкриті коди (open source)
- Система відкату

Серед переваг SQLite – відсутність потреби у встановленні та адмініструванні СКБД (на відміну від MySQL, PostageSQL чи Oracle), і відповідно можливість використовувати на хостінгових пакетах, що не підтримують сторонні БД. Зберігаючи всі дані в одному файлі, SQLite дозволяє швидко організувати власну БД. Великі проекти також можуть отримати перевагу від використання SQLite завдяки її швидкості та універсальності, так на php.net використовується саме ця БД для онлайн пошуку. Також SQLite успішно використовується в ролі бази даних на гаджетах, що потребують запамятовування – таких як телефони, PDA чи mp3 плеєри. На сайті SQLite можна знайти ряд компаній, що користуються бібліотекою – це такі гіганти як Aple, Google, Microsoft, Skype, Symbian тощо.

Маленька. Швидка. Надійна. – саме так написано про SQLite на офіційному сайті.

Мені не довелось використати всіх можливостей SQLite, але скажу лише, шо труднощів працювати з бібліотекою не було.

Основна відмінність SQLite від інших БД – в SQLite немає типів даних. Хоча типи стовбців можна вказувати при створенні таблиці – VARCHAR, TEXT, INTEGER, FLOAT і т.д., вони будуть братись до уваги лише при сортуванні та порівнянні даних – тоді розрізняються текстові та числові значення даних, які й порівнюються по-різному.

Для демонстрації використання SQLite, приведу простий приклад коду на PHP:

<?php
 
// Потрібна можливість запису в каталог, у якому буде розміщено базу даних
define('DB_ADDR', 'db/database.db');
 
// Відкрити БД або створити якщо вона не існує
$db = sqlite_open(DB_ADDR) or die("Failed to open/create the database");
 
// Створюємо таблицю (в ній будуть ті, хто підписався на уявну розсилку новин)
$query = "
	CREATE TABLE subscribers(
		datetime VARCHAR,
		name VARCHAR,
		email VARCHAR,
		status INTEGER
	);
";
// Мало чим відрізняється від mysql_query():
sqlite_query($db, $query);
 
// Запис даних в БД. Будем вважати що ім'я та електронна адреса введена користувачами, саме тому їх екрануємо
$cubscribers_arr = array(
	0 => array(
			'name' => 'Roman',
			'email' => 'mail@example.com'
		),
	1 => array(
			'name' => 'Vasyl',
			'email' => 'mail2@example.com'
		)
);
foreach($cubscribers_arr as $v) {
	$query = "
		INSERT INTO subscribers
		(datetime, name, email, status)
		VALUES
		('".time()."', '".sqlite_escape_string($v['name'])."', '".sqlite_escape_string($v['email'])."', '1');
	";
	sqlite_query($db, $query);
}
 
// Вивід інформації з БД
$query = "
	SELECT datetime, name, email
	FROM subscribers
	WHERE status == '1'
	ORDER BY name ASC
";
$result = sqlite_query($db, $query);
if($result) {
	while($row = sqlite_fetch_array($result)) {
		echo $row['name'].' <'.$row['email'].'> are subscribed at '.date("Y-m-d H:i", $row['datetime']).'<br />';
	}
}
?>

Як видно з приведеного коду, нічого складного немає – функції PHP для роботи з SQLite виглядають схоже на функції для роботи з MySQL, тому не потребують окремого спеціалізованого вивчення. Тобто достатньо знати сам SQL, і кілька основних функцій PHP для взаємодії з SQLite для повноцінної роботи з цією БД.

Окремої розмови потребує тема зберігання часу в SQLite. Оскільки спеціального типу даних для зберігання дати та часу в SQLite немає, такі дані зберігаються як текст – або у форматі UNIX timestamp – генерується функцією PHP time() або у форматі ISO – виглядає як 2009-06-14 19:26:19

Отож, буду резюмувати, що SQLite як БД цілком придатна для використання на невеликих базах даних з нескладними таблицями і при нескладних запитах (для інших поки не випробовував) і що в таких випадках особливо не відрізняється від звичного для мене MySQL.

Ну і наостанок кілька практичних порад щодо організації розробки під веб.

По-перше, з’ясовуйте наперед з замовниками такі деталі, як те, де будуть зберігатись дані – у файлах чи базі даних, якій саме БД (хоча, це більше стосується специфічних веб-проектів а не звичайних веб-сайтів).

По-друге, застосовуючи архітектуру MVC у своїй роботі ви отримуєте ряд переваг, одна з яких описана у предісторії до цієї статті. Тому старайтесь слідувати архітектурі проектування, при якій всі функції по роботі з БД (Model) описуються в одному місці, всі функції що відповідають за вигляд (View) – в другому, а код,и що реалізовує бізнес-логіку програм (Controller) в третьому.

Якщо у вас є досвід роботи з SQLite, цікаво буде почитати про нього в коментарях.

От і все, про що я хотів сьогодні написати. Дякую за увагу. Більше про SQLite можна прочитати на:

sqlite.org (en)

php.net (ru)

wikipedia.org (ua)

А справа ось у чому. На днях одна людина розповіла про смерть її знайомого. З цим знайомим вона давно не бачилась. При цьому додала, що він у неї в Однокласниках в друзях. Останній факт і змусив мене замислитись. Виходить, в реальності людини вже немає, але його профайл в однокласниках чи інших соціальних мережах (той же ВКонтакте) залишився і продовжує функціонувати. Цікавим тут є і ще один момент. Дехто з друзів, які були не настільки близькі, або у яких не було спільних знайомих із покійним, так і не дізнались вчасно, що їх товариша вже немає на цьому світі. І от, ці друзі пишуть йому повідомлення, додають на фотографіях, “додають в друзі” тощо. Причому, пізніше навіть ображаються, адже він їх ігнорує. Подивимся з іншого боку: у тебе “в друзях” людина, якої вже немає, і яка жодного руху ні в житті, ні в інтернет більше не зробить. Постає запитання – “що з нею робити?”. Видалити? Залишити, для памяті? Разом з живими друзями? Бррр.. Містика! Якось моторошно стало, правда?

А тепер відійдемо від морально-етичної частини статті, і поговоримо про інше. Ще одна причина, чому мене цікавить така тема – професійна. Як людина, яка працює у сфері інтернет-програмування, мені час від часу доводиться займатись проектувнням. Зазвичай, при проектуванні певної системи, закладається функціонал на максимум можливих випадків її життя. Наприклад, при проектуванні соціальної мережі, необхідно зважати на максимум різних дій користувача в системі, починаючи від спроб взлому чи розсилання спаму, закінчуючи невеликими деталями щодо зручності (usability) користувачів. Такі проблеми краще передбачити на стадії проектування проекту. Так от, мені цікаво, чи хоча б хтось серед розробників соціальних сервісів додумався до того, що користувачі їх системи можуть банально піти з життя? Можливо хтось скаже, що я надто далеко дивлюсь. Але ж на дворі 21 сторіччя, а інтерфейси інформаційних сервісів роблять максимально доступними і простими для розуміння навіть дітей. А також, відповідно, і максимально гнучкими; тому на таку річ як смерть також потрібно зважати.

Спитаєте, що для цього зробив би я, якби був розробником подібної (до ВКонтакте, для прикладу) системи? Нічого надто інноваційного чи особливого я зараз не скажу. Отож, треба прояснити дві речі: перше – коли саме робити якісь заходи; друге – що саме робити. Якщо користувач не логіниться в систему довгий час (наприклад пів року), кількість друзів різко зменшилась (сюди можна додати ще й недвозначні повідомлення про користувача, які приходять в адміністрацію), – це значить, що можна починати. Далі з певним інтервалом на пошту користувача потрібно вислати кілька листів, які б повідомляли про те, що його аккуант припине свою діяльність, якщо він не підтвердить (пройде за певним посиланням) своє бажання користуватись сервісом. Якщо протягом певного часу відповіді не буде, аккуант потрібно закрити. Всіх даних про користувача знищувати не потрібно(!), адже може бути й таке, що він просто собі виїхав кудись, наприклад в Африку, подалі від людей, інтернету і суєти, десь так на рік часу. В такому разі, повернувшись, користувач зможе легко відновити свій профайл у сервісі. Також не потрібно взагалі забирати ті речі, які відносяться до інших користувачів (наприклад, якщо на фотографіях користувача відмічені його друзі). Ну от, здається і все, що потрібно зробити.

Можливо у когось також є думки, що стосуються даної тематики? Буду вдячний за цікаві коментарі.

Практично завжди є речі, які повторюються у кожному проекті і які можна оптимізувати. Це твердження справедливе і відносно html-верстки: основи (кістяки) майже усіх веб-сторінок схожі між собою, і відрізняються лише деталями. Так от, дозвольте представити інструмент, який дозволяє значно птимізувати роботу на початковому етапі html-верстки – CSSLayoutGenerator. На сайті, в режимі онлайн, Ви вибираєте тип верстки (резинова чи фіксована), вказуєте де повинні розміщуватись сайдбари, та обираєте додаткові фішки (наприклад, прижати футер до низу). Як результат, генерується html/css-файл, який можна скачати на свій комп’ютер і продовжити на його основі html-верстку. Дуже зручний, і абсолютно безкоштовний інструмент, який я вже встиг успішно випробувати на одному проекті, – в ньому потрібно було зробити кілька макетів. Залишається лише сказати “дякую” розробникам – Dimox & molodoy.

Користуйтесь – CSSLayoutGenerator.

Під час серфінгу мережею я часто натикаюсь на сайти, на яких зазначений застарілий рік копірайту. Тобто при теперішньому 2009-му році зазначений, наприклад, 2008 рік. Причому це не якісь там богом забуті, а функціонуючі розкручені сайти. За приклад візму сайт банку vab.ua, сайт про погоду gismeteo.ua та сайт Львова lviv.ua. Погодьтесь, це зовсім не додає веб-сайту пристижу.

Мал. Застарілий copyright

Для того, щоб на вашому сайті постійно був актуальний копірайт, замість статичного запису можна вставити такі строки коду (приклад на php):

<?php
define('COPYRIGHT_YEAR_FROM', '2009');
if(date('Y') == COPYRIGHT_YEAR_FROM) {
	echo '&copy; '.COPYRIGHT_YEAR_FROM;
}
else {
	echo '&copy; '.COPYRIGHT_YEAR_FROM.'-'.date('Y');
}
?>

А ви вже перевірили, чи не застарів ваш сайт?

Але, якщо ви вважаєте, що створені вами веб-сторінки повинні нормально відображатись у всіх популярних браузерах (і в IE6 в тому числі), тоді давайте повернемось до теми даної статті. Проблеми з прозорістю PNG-малюнків в MSIE6 вирішуються з допомогою підключення до html-сторінки спеціального JS-скрипта: в заголовку html-документа (між тегами <head> і </head>) потрібно вставити наступний код:

<!--[if lte IE 6.0]>
<script type="text/javascript" language="javascript" src="pngfix.js"></script>
<![endif]-->

Думаю, все зрозуміло – якщо IE 6.0, тоді підключається спеціальний JS-скрипт.
Ну, і власне сам файл pngfix.js