понедельник, 19 ноября 2012 г.

A HREF. Выпуск 10


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

Разработка

Сервисы

Научное

Fun

Offtop

  • Singularity Chess - а..!
  • FiM++ - Тьюринг полный язык написания программ в стиле писем Принцессе Селестии.

пятница, 19 октября 2012 г.

A HREF. Выпуск 9

Сегодня много в разделе Fun, но так пятница же.


События - YAC 2012

Я там был. :)  Очень приятное количество студентов. В некоторые залы было физически не зайти. Народу было явно больше, чем ожидал Яндекс.

Они уже начинают выкладывать видео.

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

Разработка

Сервисы

  • WebRTC.io - экспериментальная реализация WebRTC сервиса, для видео вещания p2p в бразере. Мы запускали в офисе, работает.

Хостинг, виртуализация, облака

Продуктивность

Бизнес

Fun


понедельник, 27 августа 2012 г.

A HREF. Выпуск 8

Очень хотелось бы найти время на продолжение серии статей про структурирование, но пока его нет. Зато есть порция свежих ссылок.

Кстати, я поставил на блог комментарии от Disqus, теперь можно быстро авторизоваться из внешних сервисов, типа твиттера.

Разработка

Сервисы

Новый раздел.
  • MapBox Static API - генерирует статичную картинку с картой OSM, параметры передаются прямо в URL

Хостинг, виртуализация, облака

Fun

Прочее


понедельник, 30 июля 2012 г.

A HREF. Выпуск 7

Залежавшиеся и свежие ссылки.

Разработка

Хостинг, виртуализация, облака

Научное

Продуктивность

Прочее

вторник, 17 июля 2012 г.

A HREF. Выпуск 6

Разработка

Хостинг, виртуализация, облака

  • Domain Name Analysis - для .com и .net
  • blueprint - Reverse engineer server configuration. Можно сделать конфиг для Puppet или Chef из уже настроенного сервера. Особенно вкусно с vagrant, который я постоянно всем рекомендую.

Научное

Продуктивность

События

Прочее

вторник, 5 июня 2012 г.

Выпуск 10. Структурируй это! - часть 2 - Умные мысли


Я решил разбить тему "Структурируй это!" на больше чем две части и превратить повествование в набор заметок по разным темам. Полный список заметок можно посмотреть по соответствующему тегу.


Умные мысли


Если мысль не записана, её не существует. Всегда стараюсь действовать согласно этому принципу, любую умную мысль нужно записать. Форматы разные: если мысль короткая я записываю в список только её название. Если идея комплексная я делаю MindMap, куда ввожу общую структуру своей задумки.

MindMap ("интеллектуальные карты") - это мощный инструмент формализованный в 50-х годах XX века. Подробное описание можно прочитать в Википедии.

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

Вот, например, MindMap по моему home project:

MindMap example

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

Я использую FreeMind, это написанное на Java приложение, которое работает на всех платформах.


Анонсы на следующие выпуски

  • инструменты/сервисы, которые я использую - Evernote, RTM, uKeeper, Gmail, Dropbox, Google Contacts ...
  • автоматический разбор почты;
  • работа с файлами и папками по проектам, поиск;
  • структурирование информационно-новостного потока;
  • полезные советы и вопросы самому себе, которые позволят оценить насколько хорошо продумана структура.
Не переключайтесь!

среда, 23 мая 2012 г.

A HREF. Выпуск 5

Сейчас занят и дома, и на работе. Поэтому спец. выпуск будет когда будет время. А пока хорошая порция ссылок.


Разработка

Хостинг, виртуализация, облака

Научное

Продуктивность

Бизнес

События

Прочее

Offtop


суббота, 5 мая 2012 г.

A HREF. Выпуск 4


Продолжение спец. выпуска "Структурируй это", будет чуть позже. Пока очередной набор бес полезных ссылок.


Разработка

Хостинг, виртуализация, облака

Научное

Продуктивность

Бизнес

События

  • Видео с #MBLT12 - как и обещал видео с конференции по моб. разработкам и около того. Ещё не смотрел, если будет что-нибудь интересное, напишу позже.

Fun

Прочее


    среда, 25 апреля 2012 г.

    Выпуск 9. Структурируй это! - часть 1

    Спец. выпуск в двух частях.

    Структурируй это!


    Все мы часто сталкиваемся с большим потоком разнородной информации, часть из которой мы генерируем сами, часть приходит к нам снаружи. Email, документы, файлы, исходный код, набор полезных мыслей и т.д. Если не принимать усилий, любой такой ручеёк информации со временем превращается в хаос.

    Естественно, что все мы что-то делаем, чтобы эти данные структурировать. Я покажу, какие способы и инструменты использую я. Возможно, что-то вам покажется интересным.

    Общие идеи


    1. Структура ранее наполнения. Я всегда стараюсь придумать некоторую структуру для хранения данных до того, как большие объёмы информации начинают поступать. Это может быть, как горизонтальное структурирование (теги, даты документа, номера договоров  ...), так и вертикальное (дерево папок).

    2.  Не страшно если структура окажется не удачной, плохая структура лучше чем её отсутствие. Сделать хорошую структуру из плохой проще, чем хорошую и никакой.

    3. Наличие структуры заранее – это хороший способ не создавать бардака в последующем. Например, имея одну папку в документации по проекту с названием "Техническая документация", класть затем счёт на первый уровень уже "не захочется", логично будет создать что-то вроде "Бухгалтерские документы".

    4. Архивные данные тоже нуждаются в структурировании. Хоть это и не приятно, заниматься "бесполезной" работой по разбору того, что уже не актуально, это нужно делать. В противном случае эти данные просто "утонут" и когда они снова понадобятся (кто хоть раз делал готовые отчёты меня поймёт) приедятся тратить ещё больше времени. Часто архивные данные я структурирую менее детально, чем текущие, но это лучше, чем ничего.

    5. Подход  к  структуре дело индивидуальное. Ассоциативная память штука крайне непростая. Деление, которое для одного удобно, совершенно не очевидно для другого. Тяжелее когда над данными необходимо работать совместно, но в нашей работе – это каждодневная необходимость. Тут сработает подход "Кому наиболее важно быстро находить информацию?". Например, проектная документация наиболее полезна для руководителя проекта, поэтому её структура должна быть такой, какая удобна ему. С бухгалтерскими документами всё может быть по-другому.

    6. Не переусердствовать. Излишне глубокая структура тоже плохо. Я везде стараюсь не превышать без лишний необходимости 2-х уровней.

    Почта


    1. Держи inbox пустым. "Входящие" – это показания к действию, то что вам нужно делать. Всё остальное должно быть спрятано в архив, а лучше разложено по папкам.

    2. Пользуйся автоматическими фильтрами. Совет коррелирует с п. 1. Чем больше автоматических фильтров отсеивают вашу почту, тем лучше. Меньше лишних для работы писем в inbox, меньше времени тратиться на ручное структурирование. Сейчас уже все распространённые программы/сервисы для работы с почтой это позволяют. У меня в рабочей почте на данный момент 21 фильтр.

    Исходный код


    С исходным кодом проектов чуть-чуть другая история. Но тут тоже работает правило  "Кому наиболее важно быстро находить информацию?" хотя и в немного перекошенном виде.

    Нужно придерживаться одной идеологии в одинаковых сферах применения. Скажем, для веб-движка, должна быть одна структура хранения во всех проектах. И это должно относится не только к раскладыванию кода, но и к таким вещам, как, например, картинки и css.

    Если используется фреймворк, часто он рекомендует или заставляет использовать определённую структуру. И её стоит придерживаться. Это сэкономит время на разъяснение структуры новым разработчикам, вместо этого их можно будет отправить читать соответствующий раздел документации. В фреймворках с принципом "соглашение ранее конфигурации", это ещё и экономит время на указание движку нестандартной структуры проекта.

    Задачи


    Сразу оговорюсь, что я имею дело с проектами, длящимися годами. Поэтому мой подход может отличаться от того, который удобен при создании сайта за 3 месяца.

    1. Собирать задачи в этапы. Этапы не имеют прямой связи с версией проекта. Иногда в одном этапе выпускается несколько версий, иногда версия длиться больше одного этапа. Это некоторое психологическое деление, которое удобно руководителю проекта. Все задачи в голове связываются с их этапом. Это позволяет затем проще в них ориентироваться ("а ... это было на этапе N, мы ещё тогда добавили классную фичу X и активно разрабатывали фичу Y, помню-помню"). Я больше помню развитие проекта в этапах, чем с привязкой к годам-месяцам. Иногда я начинаю этапы, по некоторым значимым событиям. Например, при переходе на GIT я сделал новый этап проекта.

    2. Делить задачи по области влияния. В последнее время, я делю задачи именно так, а не по отношению к модулю или подсистеме. Грубо, это ответ "для чего это было сделано?", а не "где это было сделано?". Это удобнее для менеджеров проекта, потому что им не очень интересно, что вам пришлось внести изменение в класс X, куда более интересно им, что изменение было внесено для возможности Y.

    3. Собирать задачи, включаемые в каждое обновление. В Ctool я для этого использую мета-задачи. В неё вставляю связи на все задачи которые в очередное обновление нужно включить, туда же добавляю информацию о том, какие ручные действия нужно выполнить при обновлении и какую информацию нужно сообщить менеджеру или заказчикам после обновления (например, написать, что готова фича X и её можно посмотреть там-то).

    4. Писать задачу, даже если она не на 100% ясна. Если понятно, что задачу нужно будет делать, но пока не понятны детали, я заранее ставлю её в систему управления проектами и помечаю особым образом. Часто при этом у задачи есть только название, но нет ни описания, ни оценки, ни исполнителя. Такая задача служит напоминанием о том, что эти вопросы у кого-нибудь нужно уточнить.

    5. Сначала общий план, потом конкретика. Это похоже на п. 4, но здесь задачи мне уже ясны. Но я вместо того, чтобы сразу бросаться описывать каждую задачу друг за другом, сначала ставлю их все с названием, оценкой, исполнителем, а уже затем расписываю. Таким образом я буду видеть общий план и необходимое время на реализацию какой-то многоэтапной фичи, а уже расписывать могу по мере выполнения задач.

    6. Будущее тоже важно. Как я уже говорил, я веду этапы. Этап в Ctool – это мета-задача с кучей связных задач. При этом я всегда имею мета-задачу на следующий этап и часто даже на этап +2. А также имею спец. мета-задачу "Задачи на будущее" (т.н. backlog). Это позволяет мне проще отвечать на вопросы менеджеров или заказчиков "какие у вас среднесрочные/долгосрочные планы?". Я уже в общих чертах могу переставить, как будет двигаться проект.



    Хаки

    Быстрые пометки. Я использую хитрый хак, для пометок своих задач. Например все мета задачи я помечаю значком "⌘", не описанные до конца задачи - "~", бесконечные задачи - "∞" и т.д. Я стараюсь выбирать значки редко встречающиеся в названии задач (помогает таблица Unicode), чтобы потом по ним можно было строить удобные фильтры с поиском в названии задач.

    Мета-задачи. Ещё один хак, которые я использую. Для каждой новой фичи я все связные задачи собираю в одну мета-задачу (с помощью связей к задачам в Ctool). В мета-задаче я могу быстро оценить готовность различных этапов, а также в комментариях вставлять важные замечания от заказчиков и менеджеров.

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

    Comming soon


    На этом я прервусь, чтобы затем вернуться со второй частью, где я планирую:
    • рассказать о конкретных инструментах/сервисах, которые я использую;
    • рассказать как я структурирую "умные мысли";
    • рассказать как я структурирую информационно-новостной поток;
    • привести некоторые полезные советы и вопросы самому себе, которые позволят оценить насколько хорошо продумана структура.

    UPD: вместо двух частей будет целая серия заметок, смотрите соответствующий тег. Не переключайтесь!

    среда, 11 апреля 2012 г.

    A HREF. Выпуск 3

    Разработка

    Хостинг, виртуализация, облака

    Научное

    Бизнес

    События

    Прочее


    Offtop

    Новый раздел, здесь буду публиковать что-то вообще не связанное с работой. Не более 2-х ссылок за раз.

        понедельник, 2 апреля 2012 г.

        A HREF. Выпуск 2

        Разработка

        Хостинг, виртуализация, облака

        Научное

        Продуктивность

        среда, 28 марта 2012 г.

        A HREF. Выпуск 1

        Вступление


        A HREF - это новый раздел этого блога.

        Я прочитываю за неделю достаточно много информационных лент разной тематики и интересные ссылки уже давно собираю для использования в новых Очевидностях. Однако эти ссылки "застаиваются" и порой даже теряют актуальность к тому, времени, когда я включаю их в очередной выпуск.

        Подсмотрев идею у link-блога addmeto.cc, я решил эти ссылки публиковать раз в неделю AS IS. В новостях Русофта такие выпуски я анонсировать не буду (кроме этого первого), поэтому если интересно получать выпуски оперативно подпишитесь на RSS ленту тега "href" этого блога.

        Тематика ссылок как и у всего блога. Ссылки буду разбивать на группы, часть ссылок особенно по началу будут из старых запасов.

        События

        • Отчет о конференции #MBLT12 - обзор конференции по мобильным технологиям от моб. приложений до коммуникаций, позже обещаю материалы и видео.

        Разработка


        Продуктивность, бизнес


        Прочее

        • Рекурсивный zip-архив - про квайны я давно знал, теперь придумали тоже самое для .zip .gz архивов, круто
        • Голографическая реальность - необычная модель построения и происхождения вселенной, которая спорна, но может быть со временем подтверждена опытами. Даже со своей институтской физикой я понял меньше половины :) но интересно.

        четверг, 15 марта 2012 г.

        Выпуск 8. Hello GIT!

        Очередной спец. выпуск.


        Hello GIT!

        Как я уже писал в новостях Русофта у нас построена вся инфраструктура для использования GIT вместо SVN.

        На GIT уже успешно переехал ЕИС, в ближайший месяц-два переедет PortalEngine (движок ЕИС).

        Ниже предлагаю части письма, которые я писал нашему ген. директору, когда обосновывал переход на GIT. Они ответят вам на вопрос "Зачем GIT, какой от него PROFIT?" (с нетехнической точки зрения). На многие технические вопросы для программистов я уже ответил в Вики.



        Git

        GIt - это система работы с исходным кодом (аналог используемого нами сейчас SVN). У неё есть важные технические отличия от SVN.

        Углубляться в них не буду. Главное, что они позволяют добавиться нескольких преимуществ в разработке:

        • Возможность изолирования изменения по одной или нескольким задачам (в т.н. "ветку"). При это над веткой может работать несколько человек, а по её готовности и проверке она "вливается" в основной код (основную ветку).
        • Что в свою очередь позволяет более гибко выпускать обновления и исправления на рабочем сервере. Сейчас нередко ситуация когда нужно выпускать очередное обновление, а какая-то одна задача тормозит процесс, но простым способом "выкинуть" её из текущего кода. С Git таких проблем нет. 
        • GIT упрощает Hot Fixes, когда на уже выпущенной на рабочий сервер версии есть ошибки и нужно внести изменения. С SVN часто бывало, что наша разработка уже ушла вперёд и просто так протестировать и выложить исправления мы не можем. С GIT это решается более просто.
        • GIT "поощряет" часты и маленькие "коммиты" (фиксацию изменений), в отличии от SVN где коммит часто у разработчика результат работы за день-два. Чем меньше коммит, чем проще в последующем анализировать историю при поиске ошибок и объединения изменений.
        • В GIT возможна организации различных хитрых подходов к разработке. Например, когда в production (рабочую) версию системы разработчики не могут сами внести изменения, а только через руководителя проекта. Он проверяет изменения и после этого подтверждаю их внесение. Для начала у нас будет коммунизм, но со временем я буду вводить некоторые "бюрократические" схемы.
        • GIT быстрее чем SVN, хотя для нас это не особо критично.
        • С GIT в случае падения сервера с репозиторием, мы сможем полноценно продолжить работу, ничего не потеряв (один из нас может "назвать" себя сервером и работать, как раньше).

        Чтобы перейти на GIT код ЕИС переписывать никак не нужно, но нужно поменять некоторые автоматические утилиты, которые мы используем при разработке и которые были завязаны на SVN:

        • сбор ядра Pe
        • обновление ядра в ЕИС
        • сбор обновлений для рабочего ЕИС



        P.S.

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

        понедельник, 5 марта 2012 г.

        Выпуск 7. PHP 5.4 released

        И так вышел релиз php 5.4.

        Список нововведений, несовместимостей и руководство по миграции можно посмотреть на сайте php.net, полный change log тоже доступен.



        Язык / интерпретатор

        Из наиболее интересных изменений в языке/интерпритаторе:

        Trait (типажи)

        Cм. мою статью на Хабре, я её также собираюсь обновить, так как в релизе появилось пару новых полезных возможностей).

        Dereferencing (разыменование)

        Появилось для array и объектов, проще объяснить на примере:


          //array
          function abc() {
             return array('year' => 2012, 'month' => 12);
          }
          $year = abc()['year'];

          //object
          ( new DateTime() )->format('d.m.Y H:i'); 
          //обратите внимание на скобки, без них так не сработает


        Тестовый сервер

        Для разработки нужд теперь можно поднимать тестовый веб-сервер, прямо из php command line. Хороший вариант для тех, кто ленится разворачивать у себя на Windows тестовую машину (для linux это проще).

        Не вздумайте использовать в production.

        Подробности в документации.

        Закопали наконец Выкинули magic_quotes и safe_mode.


        Короткая запись массива и хеш-массива

          $a = ['title' => 'Yo', 'tags' => ['rap', 'yo']]; 
          $b = array('title' => 'Yo', 'tags' => array('rap', 'yo'));
          $a === $b; // => true

        Closure с поддержкой $this, которые можно "перевешивать"

        Примерно как Function.prototype.apply, Function.prototype.call в php.
        Про это напишу подробнее когда-нибудь позже. Например, это позволит динамически "собирать" функциональность объектов.

        Пока см. manual.


        Стандартная библиотека

        Из наиболее интересных изменений библиотеки:

        • json_encode с флагом поддержки прямого unicode (без escape последовательностей, типа \u****,  теперь просто в UTF-8) - позволит ускорить обработку таких json в браузере и формирование на сервере
        • реализация объекта сессий (вместо набора кучи фукнций)
        • новые SPL классы (а вы ещё не знаете/не используете SPL? Срочно читать manual).

        Не совместимости

        Большинство заметит только пару новых reserved words и удаленые древние фукнции:
        session_is_registered(), session_register() и session_unregister().

        Полный список.


        Спасибо Вове А. за помощь в написании статьи.

        пятница, 27 января 2012 г.

        Выпуск 6. Короткий

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



        Продуктивность




        Программирование