Originally published at Развитие личности, лайфхак, личный опыт, проекты и околоайтишные размышления. Персональный блог Станислава Малкина. You can comment here or there.

1. 25 ноября выступаю на форуме фрилансеров с докладом на тему «Сложные ситуации с заказчиками»
2. Заканчиваю допиливание своего проекта и приступлю к поиску инвестора для проекта, т.к. проект доказал свою жизнеспособность и интерес аудитории (порядка 1 500 уникальных пользователей ежедневно посещают ресурс). Своих денежных ресурсов уже не хватает для развития проекта, нужна динамика поступательного развития. Скоро напишу анонс — проект довольно амбициозный, но как всегда, только жизнь покажет его судьбу. Проект — не стартап в классическом понимании
3. Хочу продолжить писать в блог, правда пока не ясно, как это будет сочетаться с управлением проектом, о котором я написал выше и свободным временем для написания статей. Но буду стараться. Хочу снова оживить свой блог полезными материалами
4. Планирую попробовать организовывать мелкие встречи с читателями блога, чтобы быть ближе к друг другу и обмениваться полезной информацией

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

Originally published at Развитие личности, лайфхак, личный опыт, проекты и околоайтишные размышления. Персональный блог Станислава Малкина. You can comment here or there.

В частности я буду иметь ввиду проекты на PHP, но некоторые советы возможно применять и к другим языкам.

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

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

Итак, мой набор советов.

1. Выключайте отображение ошибок на продакшене. Очень частая ошибка, избегайте ее, незачем давать пищу для размышлений для взломщиков. На экран пользователя не должна вообще отображаться какая-либо информация о серверной части, а тем более ошибки. Сделать это можно поместив в .htaccess строку php_flag display_errors Off
2. Путь на файловой системе. Не используйте никогда директив по типу define (’PATH_ROOT’, ’/hosting/bla-bla/’) . Это глупая стратегия. Каждый раз править настройки при переносе проекта на другой сервер — абсурд. Используйте «магическую константу» __FILE__ , которая моментально вернет путь к текущему файлу (допустим конфигу), от которого можно получить нужный путь к корню проекта.
3. Ядро проекта. Контроллеры, модели и прочее должно лежать как минимум на уровень выше, чем часть, доступная через веб-браузер. Хорошая стратегия строить приложение так — что директория ядра и директория, указанная в  DOCUMENT_ROOT — лежали на одном уровне (у меня эти папки обычно имеются как application и public). Данное разграничение призвано обезопасить проект от перезаписи файлов через уязвимость в проекте. Хорошей практикой также будет снять бит на запись от имени пользователя, под которым запущен веб-сервер.
4. Загрузка файлов, изображений и т.д. Допустим, что все загружаемые файлы кладутся в папку uploads в папке public. Тогда первым делом лучше всего положить в папку uploads файлик .htaccess со следующей строкой — php_flag engine off — это поможет защититься от любителей залить бекдор через уязвимость в коде загрузки файлов на сервер. Это конечно слабая защита от загрузки бекдоров на других языках (например на перле), но «школьники» уже не пройдут. А лучше всего конечно делать безопасную загрузку, без уязвимостей. Но на всякий случай рекомендую подстраховаться таким образом — лишним не будет. Строка запрещает выполнение пхп-кода из данной папки и подпапок.
5. Мультиязычность. Планируйте возможность мультиязычности еще на этапе проектирования и создания приложения, даже если это сейчас и не нужно. Это съекономит много сил и нервов, когда «вдруг» мультиязычность понадобиться, а в ядре ничего не заложено для этого. На подобные грабли в свое время наступил проект connect.ua, не повторяйте чужих ошибок
6. Оптимизируйте все до того, как появятся нагрузки. Не стоит ждать, пока проект начнет тормозить под нагрузками и только тогда решать вопрос. Поставьте изначально байт-кешеры кода, например eAccelerator (или другие по вкусу), настройте кеширование на стороне клиента (хорошие советы в этом плане можно найти на webo.in) и на сервере. Это даст существенный прирост производительности (иногда порядка 300 и более процентов), что существенно снизит нагрузки и повысит скорость загрузки страниц у пользователей.
7. Настройте оповещение об измененных файлах за сутки. Я обычно это делаю через помещение в крон строки: 0       0       *       *       *       find /path/to/public/dir -mtime 0 | mailx -s «report :)» my@mail.com > /dev/null 2>&1 , после этого мне раз в сутки приходит список измененных файлов в директории, анализируя который можно понять, все ли хорошо. Тоже самое можно настроить и для ядра проекта. Данный отчет однажды спас меня, когда произошел взлом одного из моих проектов и по всей фс были накиданы бекдоры — через эти списки мне легко удалось всех их удалить, без поднятия проекта из бекапа. Лично для меня — это теперь незаменимая вещь, лог которой я просматриваю раз в сутки обязательно на наличие подозрительных изменений.
8. Всю разработку ведите на SVN и на дев-сервере. Не стоит делать правок «наживо» на продакшене. Я считаю оптимальным — настроить SVN так, чтобы при комите данные сразу попадали на дев-сервер, где можно еще раз протестировать сделанные изменения. Это очень удобно для разработки и тестирования. Как правило дев-сервер может быть отдельной машиной, но также это может быть и виртуал-хост на той же машине, где и продакшн. Правда последний вариант не рекомендую, т.к. при тестировании могут быть разные ситуации, вплоть до зацикливания кода и нехорошо, когда это влияет на работу текущих пользователей.

Если еще что-то вспомню важное — допишу.

Успехов!

Originally published at Развитие личности, лайфхак, личный опыт, проекты и околоайтишные размышления. Персональный блог Станислава Малкина. You can comment here or there.

Иногда хочется просто прокричать это на весь мир, чтобы те, кто еще не слышал этого, наконец-то услышали.

С конца февраля я работаю в роли Senior PHP Developer над проектом (довольно большим и амбициозным), который 10 (!) месяцев разрабатывался абсолютно без ведения какой-либо документации (ну разве что диаграмма базы есть) к проекту и коду.

Естественно приходится постоянно пинать напарника, который 10 месяцев это разрабатывал. Он понимает важность написания документации, но такова была воля заказчика, так как ему надо было «быстрее получить результат, чтобы отчитаться перед инвесторами/заказчиками».

И дело даже не в том, что код плохой или что-то такое. Код нормальный, вменяемый, на Zend Framework, но ведь от этого легче не стает, так как система за 10 месяцев стала довольно огромной, а мне приходится вникать в нее с нуля.

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

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

Экономьте свое время и время вашей команды уже в самом начале, а не после того, как «припекло».

Originally published at anycolor's home. You can comment here or there.

Сегодня стартовал новый сезон Кубка Мира по биатлону. Так, как я большой фанат биатлона и наших спортсменов в частности и мне всегда хотелось что-то сделать для развития биатлона в нашей стране, то я решил, что лучше будет, если я просто сделаю сайт о биатлоне, ведь в каждой стране есть как минимум 2-3 сайта о биатлоне, а в нашей стране только один - http://biathlon.com.ua . Немного подумав, я решил, что это слишком мало.

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

Очень надеюсь, что я не один фанат этого прекрасного вида спорта!