This version of the page http://malkin.com.ua/&add_id=7/ (0.0.0.0) stored by archive.org.ua. It represents a snapshot of the page as of 2009-10-17. The original page over time could change.
Развитие личности, лайфхак, личный опыт, проекты и околоайтишные размышления. Персональный блог Станислава Малкина


Авг
22
В продолжение истории

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

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

В общем-то кому интересна эта история — милости прошу — читайте (внимание, много текста, много комментариев), в конце приложен мой комментарий на всю тему.

Возможно мой опыт кому-то пригодиться из читающих меня.

Добавить в


Авг
17
Первое правило при работе с русскоговорящими заказчиками

Если можете не работать — не работайте. Так как чаще всего попадаются разные засранцы.

Всегда берите с них предоплату, не менее 30% от стоимости проекта, иначе будет вероятность, что ввиду каких-либо обстоятельств больше вам ничего не заплатят.

Если проект критичен заказчику по времени, то давайте накрутку в 30–40%, при этом озвучивайте, что это накрутка за важность и спешку, чтобы потом не было удивленных лиц по типу «ты много попросил, я согласился только потому, что думал, что ты как фрилансер все сделаешь сам, от а до я, ведь цена у тебя большая, больше, чем у людей, которые у меня работают в офисе и делают все по ТЗ».

Большинство клиентов не понимает, что тестирование никак не входит в стоимость проекта, когда идет речь о разработке движка и это отдельный пункт, который нужно проговаривать сразу, чтобы было понимание откуда береться цена допустим в 2500$ за 3–4 недели работы.

Не откладывайте оплату куска работы ни при каких обстоятельствах на последний день, даже если заказчик говорят, что «пару багов это не 100% сделанная работа, принимать не буду». Баги нужно исправлять, это и ежу понятно, но когда отказываются платить часть денег за этап, кивая на пару мелких багов — повод задуматься, а стоит ли их исправлять и надеяться, что клиент заплатит, иначе можно потерять кучу времени, в результате не увидев никакой оплаты.

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

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

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

Можете не работать с русскоговорящими заказчиками? Не работайте. Из личного опыта могу сказать, что иностранец никогда не станет относиться к вам с недоверием и тем более — всегда заплатит за работу, которая будет проделана, особенно если проект ему нужен.

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

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

Добавить в


Июл
10
А тем временем…

За делами и заботами, я совсем забыл, что 2 июля блогу исполнилось 2 года!

С чем себя собственно и поздравляю, а также читателей, которые были и есть со мной на протяжении этих лет

Спасибо вам за вашу поддержку и интерес к моей личности и моим мыслям на IT тематику

Добавить в


Июл
10
Тысяча подписчиков: это много или мало?

Если верить моему счетчику — у меня 724 подписчика статусом на сегодня. Несмотря на то, что цифра не маленькая и очень близкая к 1000, я считаю, что 1000, как заветную границу абсолютно не стоит ставить за самоцель.

Хотя бы просто потому, что из 1000 читателей, большая часть может вообще не посещать блог практически никогда, кроме момента, когда они подписались.

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

Таким образом встает вопрос: а что дают цифры на счетчике? Как на меня это цифра, которая позволяет поднять свое ЧСВ и ничего более. Читать полностью »

Добавить в


Июл
06
Почему лучше не связываться с реселлерами доменов

Чтобы не было ситуаций, как у меня: когда вопрос продления домена решался несколько недель, т.к. контакт реселлера не отвечал, а по-другому продлить домен никак не удалось, т.к. не успел его оплатить вовремя через панель доменной компании.

Хорошо, что компания-реселлер — компания, где я работал пару лет назад и остались контакты начальства. Только благодаря этому вопрос решился быстрее и вообще решился.

Теперь блог снова в онлайне!

P. S. Скоро напишу о своем новом проекте.

Добавить в


Апр
13
Пару советов по созданию проектов

В частности я буду иметь ввиду проекты на 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 так, чтобы при комите данные сразу попадали на дев-сервер, где можно еще раз протестировать сделанные изменения. Это очень удобно для разработки и тестирования. Как правило дев-сервер может быть отдельной машиной, но также это может быть и виртуал-хост на той же машине, где и продакшн. Правда последний вариант не рекомендую, т.к. при тестировании могут быть разные ситуации, вплоть до зацикливания кода и нехорошо, когда это влияет на работу текущих пользователей.

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

Успехов!

Добавить в


Апр
08
Мне 24!

Да, сегодня.

Добавить в


Мар
14
Пишите документацию к проекту и коду!

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

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

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

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

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

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

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

Добавить в


Мар
12
Стартап с нулевыми вложениями - миф?

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

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

Добавить в


Мар
02
Последние новости с полей

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

Самые упорные читатели думаю заметили, что меня давно не было и я ничего не писал.

Не потому, что не о чем, просто очень и очень занят был. К слову говоря — 24 февраля я стал дипломированным специалистом.

Теперь я специалист по теоретической математике, LOL. Так или иначе — высшее образование — важный шаг в развитии каждого человека, пусть даже наличие этой бумажки и не гарантирует абсолютно ничего, но является приятным дополнением к существующему опыту и навыкам. Да, да, принимаю поздравления. Читать полностью »

Добавить в