Архив метки: мысли

Работа и сайд-проекты

На хабре пофвился отличный перевод

https://habr.com/ru/company/macloud/blog/553580/

Хочется для себя запомнить несколько мыслей из этого поста.

Дело в том, чтобы иметь занятость, которая не является твоей работой.

Важна игра вдолгую: наработка сети контактов и репутации, которая будет долговечнее любого работодателя.

Да, постоянная работа — это отлично, но мне нравится рост, который дают успешные сайд-проекты. Дело отнюдь не только в деньгах — бывают успешные сайд-проекты, которые НЕ ДАЮТ денег сразу.

Во-вторых, нужно наконец-то засучить рукава и найти время. Говорить легко, но только ваши дела реально демонстрируют, кем вы себя видите. Если вы говорите, что хотите творить в нерабочее время, но почти по 40 часов в неделю тратите на Youtube/Netflix, то на самом деле вы Фултаймовый Потребитель. Выделите время

Работа прокачивает шабашку, шабашка прокачивает работу.

База знаний в saas-проекте

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

Небольшой список требований к такой базе знаний и движкам, для их построения:

  1. Актуальность. Информация всегда должна быть актуальной. Поменялся интерфейс системы — меняйте скриншоты в базе знаний. Добавили новый функционал — добавьте информацию об этом в базу знаний.
  2. Структурирированность. Информации о продукте становится все больше и больше. Правильное ее структурирование обеспечит удобство использования.
  3. Поиск. Он просто должен быть и быть классным +)
  4. Простота ведения. Интерфейс администратора/оператоа должен быть элементарным (привет, конфлюенс!)

Ну и хватит пока.

Под требования выше подходит практически любая современная CMS или вики-движок, имеются и специализированные решения.

В голове рождаются мысли о написании такого движка на Symfony, постараюсь их отогнать =)

Мысли про проверки, зависимости, фреймворки, php и perl …

Продолжаю выкладывать свои мысли и соображения о php и perl (первая серия вот тут). Сегодня хотелось бы поговорить про проверку зависимостей («чекеры»так называемые). Написать эту заметку меня заставил чекер зависимостей Symfony2. Возьмем, к примеру, пхпшный Yii (или Symfony2) в дистрибутивах всех этих фреймворков есть специальная страничка/скриптик, который проверяет наличие всех необходимых расширений и системное окружение, в которое фреймворк установлен.  Почему таких страничек нет в перловых фреймворках Mojolicious, Catalyst и т.д. ?  На мой взгляд, все эти, так называемые, зависимости должны проверяться  и валидироваться при установке фреймворка/библиотеки. Беда в том, что в мире php установка, в большинстве случаев, сводится к простому копированию файлов на сервер (ну нету пока у php центрального хранилища модулей и библиотек). Как-то же необходимо узнать «правильно» ли мы все скопировали, все ли у нас теперь заработает ? Вот для этого такие странички «чекеры» и необходимы. При таком подходе к установке очень часто возникают ситуации, когда все кажется сделано: фреймворк залит, приложение залито, запускаем….ничего не работает, смотрим наш «чекер» и видим, что не хватает какого-то PDO расширения или драйвера для memcache. Отсутствующие библиотеки — это еще пол беды. Самое интересное когда работа фреймворка зависит от конфигурации php (всем известен php.ini c его сотнями параметров ? ). Т.е. имея установленный php, имея установленные все необходимые модули, наше приложение может не заработать из-за конфигурации языка программирования (!). Вот и чекер Symfony2 выдал мне варнинги (хорошо хоть не фатальные) с просьбой подкорректировать настроечки в php.ini. Наличие у языка программирования централизованного файла настроек, на мой взгляд, очень сомнительная штуковина, добавляющая лишние проблемы при распространении приложения (вот маленький пример, возникший при разработке Юпи! https://github.com/yupe/yupe/issues/203 ). А что же Perl ? А тут все просто: ставим пакеты из CPAN, при установке автоматом проверяются и ставятся все зависимости, если что-то пошло не так — установка просто закончится неудачей и нам не придется гадать «а заработает ли?». Конечно, и тут бывают проблемы, но значительно реже. У перла нет никакого конфигурационного файла, что решает еще одну проблему с установкой. Есть конечно опции компиляции, которые могут отличаться от сервера к серверу, но это настолько редко было в мой практике, что я не беру это в расчет. И снова забыл про тестирование. При установке Mojolicious (как пример) прогоняются все тесты, которые только есть в дистрибутиве фреймворка и зависимостях. Автоматическая проверка зависимостей,  их установка и прогон тестов практически всегда гарантируют работоспособность расширения на данной конкретной машине. Мысли кончились…

В заключении поделюсь ссылкой на статью Фабьена (разработчика Symfony) http://fabien.potencier.org/article/64/php-is-much-better-than-you-think