Text

Среда. Обращение к загашникам и Компьютерщики.ру

Вчера вечером, когда планировал задачи на сегодня, вспомнил, что у меня же есть пачка записок с идеями в Google Keep! Просмотрел, выкинул неактуальные, осталось как раз все интересное.

В результате, сегодня начал с доделок интерфейса bkme, потом приделал лексический анализ к ФидФильтру (осталось его только задеплоить), а на десерт оставил один из “долгождущих” проектов - маленькая игрушка под названием “компьютерщики.ру”.

Суть такова: иногда люди меряются спиписками бывших у них телефонов (сейчас меньше, но лет 5 назад было вполне модно), и я подумал, что было бы интересно померяться использованными технологиями. “Спектрум” много у кого был, а вот Commodore 64 или Atari у нас были редкостью. Идея в том, чтобы не особо ограничивать возможности добавления таких “тэгов” или “бэйджей”, и в то же время сделать саморегулируемую систему, которая не даст СЕО-шникам забить весь профиль ключевыми словами и спамить им направо и налево.

Тут пока начал делать только всякие базовые штуки, параллельно думаю насчет механизмов регулирования. Планирую на следующей неделе довести его до товарного вида и выложить на джва года лежащий домен computershiki.ru.

А на завтра у меня запланировано небольшое погружение в прикладную криптографию. Будет интересно, я думаю.

Text

Вторник. FeedFilter и ilvar.ru

Сегодня по плану занялся воскрешением FeedFilter на платформе Meteor и запилкой наконец сайтика нашей маленькой, но бодрой компании.

От Метеора по сравнению с Derby ощущения неоднозначные, примерно как от Рельсов после Джанги. У Метеора свой хитрый инсталлер, свой пакетный менеджер (почему-то просто взять один из миллиона пакетов NPM и использовать нельзя), свой Heroku-стайл микро-хостинг для моментального деплоя, и все такое. При этом, несколько странно работающая reactivity, я так и не смог автоматически класть в модель значение инпута в форме, пришлось костыль писать.

Впрочем, за счет этих странностей оно быстро ставится, быстро настраивается и приемлемо работает. Многие вещи типа аутентификации через социальные сети сделаны вообще божественно - ставишь пакет, добавляешь в шаблон один тэг, получаешь в интерфейсе в нужном месте дропдаун с кнопками входа. А что самое вусное - пока oauth не настроен, при клике на кнопку показывается попап, в котором четко расписано, куда идти, что жать, и есть форма для ввода полученных ключей. После настроек python-social-auth как бальзам на душу. Хотя я почти уверен, что у последнего список провайдеров авторизации в пару раз длиннее.

Еще удивило (как и в Derby), что нет дефолтного способа запуска всяких периодических задач на сервере, например, в моем случае это сбор обновлений RSS-потоков. Приходится ставить отдельный пакет для Ноды, который умеет с метеоровским серверным API работать напрямик, но как-то это не шибко прямо получается.

В общем, начал делать свою читалку заново, но саму фильтрацию еще не сделал. Правда, с ней будет проще - можно взять почти целиком из старой версии.

Еще сегодня наконец сделал нам приличный ilvar.ru, а то сколько клевых вещей делаем, а все сами без сапог.

Завтра планирую приделать к ФидФильтру, собственно, лексический анализ, написать тесты с Laika и задеплоить результат, а на BkMe добавить переключение городов и киллер-фичу - внесение поправок в маршруты.

Text

Понедельник. Bkme и PhoneGap

На этой неделе решил устроить небольшой марафон и каждый день делать что-то клевое, с упором на незнакомые технологии и практики.

Сегодня сделал для bkme привязку комментариев к точкам и кускам маршрута (здесь пришлось вспомнить даже школьный матан). Теперь можно при комментировании не описывать словесно “100 метров от перекрестка Пупкина и Мумкина”, а поставить точку и написать, чем эта точка хороша. Или отметить кусок маршрута и написать, что в межсезонье там дорогу размывает к чертям. А с моей стороны можно будет повторно использовать этот код для финальной цели системы комментирования - внесения поправок в чужие маршруты.

Правда, это не все. Разогнавшись, я со всего размаху вляпался в PhoneGap и сделал прототип андроидного клиента для того же bkme. Он пока что умеет только показывать карту с маркерами (как морда сайта) и называется HelloWorld.apk, но собирается, ставится и даже работает. Судя по всему, в будущем можно будет даже оффлайновые карты сделать, проблема там только в объемах — не самые подробные карты Питера (внутри КАД) весят около 100 метров, и зашивать их в apk совсем не комильфо. Надо будет подумать, как бы их так хранить отдельно, а в идеале - давать предзагружать нужный город для использования “на ходу”.

Оный PhoneGap представляет собой отличный пример java-приложения - долго (для двухметрового файла, в котором почти ничего не поменялось) компилит, весит вместе с SDK и эмулятором метров 300, и не имеет практически никаких адекватных средств дебага. Пришлось щедро обмазать код try {} catch(e) { alert(e); }, чтобы докопаться до истины и завести наконец эту карту и маркеры.

Завтра попробую реанимировать свой FeedFilter, только не на Derby, а на Meteor.

Text

FeedFilter - обучаемый RSS reader

Для своего news feed про бессмертие захотелось мне научиться собирать и фильтровать RSS-фиды так, чтобы вообще не видеть гарантированно не подходящие статьи. Тогда можно в такой аггрегатор напихать сотню разных технологических и новостных потоков, и просматривать каждый день не 200 статей, из которых 95% не по теме, а всего 20.

Поискал такой сервис - и фигушки, много где есть социальные всякие фильтры и шаринг, но откуда другие юзеры узнают, что меня интересует именно иммортализм и медицинские технологии? Эх, опять придется все самому делать.

Чтобы было веселее, взял абсолютно незнакомый мне Derby.js, код писал на абсолютно незнакомом CoffeeScript, а база у Дерби - собственный LiveDB, у которой внутри MongoDB (который я использовал в одном маленьком проекте) + Redis для PubSub.

В результате, потратил 12 часов времени, а получил (вместе с фильтрацией) всего 140 строк кода (не считая автоматически сгенерированных Дерби файлов, которые я не трогал) + шаблоны + стили.

Потестирую немного, если будет прельстиво работать - приделаю авторизацию и выложу куда-нибудь.

Tags: js node rss smart
Text

Про биткоин и бабло

После адского скачка стоимости биткоина отовсюду несется стон: ах-ах, почему я не купил в 2010 этих монеток на сдачу, был бы сейчас миллионером. На самом же деле, есть нюансы.

Во-первых, в 2010 коин был скорее игрушкой для гиков, и вкладывать в него бабло было еще более рискованно, чем в МММ. Там обычная пирамида, а тут какая-то новая система, которая может рухнуть в любой момент. Особенно учитывая, что прочие попытки сделать независимые всемирные интернет-деньги благополучно провалились (см. Liberty Reserve).

Во-вторых, да, можно вкладывать”сколько не жалко” в высокорисковые инструменты, но тогда “вложил 100 баксов” превращается во “сложил 1000 баксов в разные конторы, из них 900 сгорело”, это уже не так весело.

В-третьих, как оказывается, довольно много людей наивно считает, что деньги - следствие пользы обществу и некоей добавленной стоимости. Да, это на самом деле не совсем так, но можно же пожить немного в своем мире, с пони и единорогами?

И при таком раскладе оказывается лучше перечислить “сколько не жалко” каким-нибудь чувакам на Кикстартере, собирающим бабло на плазменный ракетный двигатель, или бюджетный электронный протез, или еще какой 3d-принтер. По крайней мере, деньги пойдут на что-то реальное, немного приблизят будущее, в котором хочется жить. И гораздо меньшую часть получат жулики, которые тупо надули пирамиду, нагребли бабла и свалили в Доминикану.

Link

sws-staff:

image

Всем привет!

Мы рады сообщить всему миру, что мы открыли наш проект для бета-тестирования. Кто-то скажет: “Фи, очередной конструктор сайтов..”. А вот и нет!

Text

Размышления о правильном конструкторе сайтов

Периодически мне пишут “знакомые знакомых”, которым нужно сделать сайт для фирмы. Я обычно отказываюсь и стараюсь их передать кому-нибудь, но часто такой клиент плохо представляет, зачем им вообще нужен сайт, и не готов тратить больше 5-10 тысяч рублей. Что можно сделать на эти деньги?

  • Можно найти школьника, который слепит сайт на “жумле” с краденым шаблоном, обычно через год такому сайту просто не продлевают хостинг, либо наоборот - он вечно висит с “новостями” трехлетней давности и фоткой генерального директора на главной.
  • Если нужен магазин - можно воспользоваться специализированным сервисом типа inSales, благо, они дают кучу разных “плюшек” вроде интеграции с Яндекс.Маркетом.
  • Если нужен не магазин, а просто визитка, есть “универсальные” конструкторы, типа того же ucoz. Неплохая штука, но идеальный ее пользователь — фанатик, которому нужно прежде всего самовыражение, и желательно бесплатно, а юзабилити и всякая там конверсия — ругательные слова. Поэтому там полно сайтов игровых “кланов” и прочих клубов по интересам, а серьезных почти нет.

Поэтому я подумал: а что, если конструктор сайтов будет содержать в себе готовые шаблоны для разных видов бизнеса? Их можно сделать сотни, от кафе до оптовой торговли канцтоварами, и забить туда только информационные блоки, убрав возможность “налить воды” и вывесить фотографию генерального. Как в IKEA - вроде собираешь все сам, но все детали точно подогнаны, собирается все легко, быстро, и не позволяет “улутшать” конструкцию.

Дальше, если у нас есть фиксированные места для конкретной информации — можно, во-первых, облегчить чтение машинам с помощью микроформатов, во-вторых, генерировать стили для всего этого добра автоматически. Хм.

Так родилась концепция: конструктор сайтов с сугубо информативными блоками (которых тоже можно сделать много, несколько десятков), из которых собираются готовые шаблоны под любой тип бизнеса (или шире, возможной задачи клиента), с автоматической генерацией дизайна, и стоимостью на уровне приличного хостинга, т.е. от 3000 в год.

Создал сайт (выбрал подходящий шаблон, думать не надо), забил туда конкретную информацию (по-военному четко, без литераторства, думать не надо), сгенерировал дизайн (т.е. нажал кнопку “сделать шедевр”, думать не надо), и все.

Минусы: компоновка разных сайтов получится более-менее одинаковая, и мы принципиально отсеиваем графоманов, которые вчера прочли статью про “продающие тексты” (но по-моему, это неплохо само по себе).

Как считаете, взлетит? Посоветовали бы такую штуку знакомым?

Text

Идея

Часто в последнее время натыкаюсь на отсутствие в различных начинаниях идеи, “внутреннего стержня”, если угодно. Проблема эта появилась совсем не в айтишной сфере, да и вообще немолода; я не удивлюсь, если ей тысяч пять лет. Но я здесь хочу немного поговорить об Идее в моей работе.

Project Manager

В любом проекте должен быть один, и только один, руководитель команды. Где-то он называется project manager, где-то product owner, но суть одна - он задает вектор движения команды, он ставит майлстоуны, и он всегда точно знает, как должен выглядеть продукт. Да, есть “команды без менеджеров”, типа github, но в них все равно есть “играющий тренер” - это нормально (даже если эта роль преходящая). Но хуже всего, когда менеджер формально есть, но видения продукта у него нет.

Юзеры

Каждый член команды должен знать юзера продукта. Не обязательно при этом жениться (или выходить замуж) за юзера, но иметь его портрет в голове надо всегда. Если юзер высокий - надо сделать дверь повыше, если низкий - кнопки пониже, если близорукий - интерфейс поконтрастнее, и так далее. Любой шаг, любая деталь должны проектироваться строго с точки зрения юзера.

Задача

РМ должен максимально ясно и однозначно донести до команды, какую задачу решает продукт. Дальше все просто: если фича не помогает решить задачу - в мусорку такую фичу (даже если она уже реализована). Хороший дизайн - такой, от которого нечего отнять (а вовсе не когда нечего добавить).

Коммуникации

Многие очень любят вести обсуждение в скайпе или по телефону, но в этих случаях нужно взять за правило после любого обсуждения формировать follow-up, и если как-то были затронуты юзеры или задача - занести результаты в документацию. Всегда. Иначе все, кто не присутствовал на обсуждении, или забыл, вправе считать, что этих решений нет и не было.

Итог

Перечисленные мною пункты - абсолютный must have для правильного понимания идеи всеми членами команды. Без такого понимания проект не взлетит совершенно точно (думаю, у многих найдутся такие примеры). Зато, если все перечисленное есть и работает, можно сделать “конфетку” даже из непритязательного клона западного сервиса.

Text

Как заставить себя работать

Многие начинающие фрилансеры не знают, как прекратить проскастинацию и начать наконец работать. Я постараюсь описать, что помогает в самомотивации лично мне.

  1. Поставь себе цель. Помните про пирамиду Маслоу. Еда и крыша над головой - это хорошо, но это низшие уровни, поэтому надо поставить себе какую-то более высокую цель. Для кого-то это покупка машины, для кого-то путешествия, для кого-то запуск стартапа своей мечты. Причем, тут нежелательно пользоваться кредитами, мозг очень по-разному воспринимает состояния “я должен накопить Х денег ради своей мечты” и “я должен отдать Х денег банку за свою мечту”. Плюс, тут вступает в действие следующий пункт.
  2. Вышвырни себя из зоны комфорта. Ничего личного, просто физиология. Множество экспериментов (хе-хе) наглядно показали, что если я сплю, сколько захочу, ем от пуза и лежу под пальмой, то работать в таком состоянии почему-то неохота. И после секса, кстати, тоже (мноого экспериментов!). Поэтому лучше вставать по будильнику, кушать по расписанию, да и под пальму ходить в отведенное время. И, главное, не в сиесту. Некоторые говорят “не хочу лишать себя удовольствий”, но для меня кайф от самореализации гораздо важнее, чем возможность лежать на пляже весь день. Тем более, если сильно приспичит - можно выделить специальный пляжный день и хоть улежаться. Главное, не в сиесту, да.
  3. Рабочее время, рабочее место Как проснешься - так и день пройдет. Если сразу взял себя в руки и начал работать - будет все хорошо, а если сначала позавтракал, потом Хабр почитал, потом RSS… а потом уже обед, а ты еще ни черта вообще не сделал. также помогает настроиться закрытая дверь в комнату (если она обычно открыта) и музыка в наушниках. Семья уже в курсе: если дверь закрыта, подходить и спрашивать, почему, не стоит :) Закончу - сам выйду.

Ну и главное - прелесть фриланса не в том, что можно валяться на диване. Прелесть в том, что ты, и только ты выбираешь, чем ты будешь заниматься. В свободе.

Text

Чеклист для больших проектов

На относительно больших веб-проектах часто встречаются проблемы в организации процесса. Поэтому я решил собрать моменты, на которые стоит обратить внимание, в единый список, с которым можно сверяться при оценке незнакомого проекта (или построении процесса с нуля).

Постановка задач

  • Нужен таск-трекер, лучше old good redmine или что-нибудь похожее. Agile-штуки вроде Pivotal или Trello хорошо работают только при поддержке agile менеджментом - маленькие задачи, короткие итерации. Если же задача требует обсуждения и уточнения - такие трекеры начинают мешать.
  • Нужен product owner, как его ни назови. Человек (или коллективный орган), который точно знает, как будет выглядеть и работать продукт. Он должен уметь понимать языки и пользователя, и разработчика, и бегло переводить с одного на другой. Если такого нет - нужно его нанять или назначить.

Сервер

  • Хостинг. Нужно иметь минимум 2 инстанса продукта - для разработки/тестирования и для выкатки на публику.
  • Нужно бэкапить как минимум продакшен, как минимум раз в неделю. Лучше раз в день. И бэкапы хранить отдельно от рабочего сервера (например, в Amazon S3).
  • Нужно иметь хранилище кода с контролем версий. Я считаю, что лучше всего для этого подходит аккаунт на github/bitbucket (в первую очередь, из-за удобного просмотра и возможности быстро показать коллегам код), в случае обострения паранойи можно держать репозиторий и на своем сервере.

Дизайн

  • Дизайнер должен быть доступен всегда. Практически всегда нужно вносить какие-то мелкие правки или добавлять элементы интерфейса. Лучше, чтобы этим занимался один человек.
  • Дизайнер должен разбираться в проектировании интерфейсов (практически тавтология, да). В Рунете часто считается, даже на больших проектах, что дизайнер рисует всякие красивости, а кнопочки и формы программисты сами раскидают. Мы, конечно, раскидаем, только результат чаще всего будет неудобен и непонятен органическим гуманоидным формам жизни.
  • Дизайн должен учитывать работу с сервисом с мобильных девайсов. Хотя бы начиная с андроидного среднего разрешения 800х480 и с тач-скрином.
  • И вообще, дизайнер должен осознавать, как его картинки будут верстаться и работать.

Верстка

  • Вопрос “дивы или таблицы” давно не стоит. Естественно, на дивах, хорошо бы - семантичная, еще лучше - на фреймворке типа bootstrap.
  • Если дизайнерские выкрутасы нельзя сверстать аккуратно - стоит попросить дизайнера переделать (если это не принципиальный элемент). Поддержка выйдет дороже.
  • В верстке должны быть все возможные состояния элементов. Если это кнопка - она должна быть в нажатом и отключенном состоянии, если форма - должны быть сверстаны поля с ошибками.
  • Я выше написал про поддержку мобильных платформ - к верстке это тем более относится.
  • Идеально, если верстальщик умеет поднять у себя проект и пользоваться репозиторием кода.

Бэкенд

  • Код должен следовать гайдлайнам языка и фреймворка. Если он писался человеком без опыта работы с конкретной платформой - код смотрим особо тщательно, будь автор хоть суперкрутой программер. Больше того, “суперкрутые”, даже чаще используют мозгодробительные конструкции, в которых никто потом не может разобраться.
  • Должна быть документация. Коментарии в коде, тесты, отдельная документация - уже не так важно, что именно. Ведущего разработчика или owner-а всегда может переехать трамвай, и нужно быть уверенным, что проект после этого не развалится, как карточный домик.
  • Обязательно должен быть поставлен процесс тестирования. Опять же, конкретные методики это та еще пища для холивара, но что-то быть должно. Иначе к запуску окажется, что все ломается, никто не знает точно, работает фича или нет, а если не работает - кто и когда ее сломал.

Коммуникации

Все члены команды должны быть связаны со всеми остальными. Давно уже у всех есть доступ в интернет, есть Skype, есть TeamViewer (if you like it - buy it!). Сотрудник, который проверяет почту раз в неделю, а отвечает на нее еще реже (при этом, сотового у него нет, потому что он Перельман) - не очень хороший сотрудник (хоть и, возможно, отличный программист). Схема, при которой все общение между верстальщиками, программистами и дизайнерами идет только через менеджера - тоже не очень эффективна. Имеет смысл ограничить “прямую” постановку задач, но вопросы типа “как вот это у тебя должно работать” должны ходить напрямую.

Мы не успеваем!!!

Если проект не укладывается в сроки или в бюджет - команда об этом должна узнать как можно раньше. Чтобы вместо “релиза” глючного, постоянно падающего и частично вообще нефункционального нечта можно было заранее обсудить сроки, урезать функциональность (почти всегда оказывается, что можно урезать что-то ресурсоемкое, но маловажное для пользователя) и выкатить рабочий продукт.

Собственно, это одна из мантр agile - постоянно иметь рабочий продукт. После первой недельной итерации мы должны иметь рабочий продукт. Да, он мало что умеет, но он работает, он не падает, и его всегда можно показать при возникновении вопроса “а чем вы тут так долго занимаетесь?”.

Методология

Лучшая методология разработки ПО

А если человек много треплется, но мало двигает дело вперед - ну его нафиг.

У нас не сработает

Если в команде мало людей (нет денег, злой заказчик и т.п.), указанные выше роли можно распределять по нескольку на одного человека. От чего-то можно отказаться совсем (например, не делать графический дизайн, а взять готовую тему для фреймворка, или вместо найма программистов взять cms), важно только осознавать “за” и “против”.

blog comments powered by Disqus