Совсем недавно я поменял свой статус с рядового программиста на предпринимателя. Ровно год назад я отработал свой последний день, работая в компании (дело было в Иордании), с тех пор я прошел путь от фрилансера до директора небольшой компании.


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

Доброго времени суток, Хабр!

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

В этой статье (а она расчитана на новичков, особенно для тех, кто слабо знаком с Linux) я опишу как быстро собрать тонкого клиента и сделать его использование достаточно безопасным. Под хабракатом использование смарт-карт, RDP-клиент фирмы 2X и хэппи-энд. Добро пожаловать!

Неуловимый Go.

Помните анекдот про неуловимого Джо? Именно восклицанием «Да кому он нужен!», прозвучавшим в форме вопроса "ЗАЧЕМ?", был встречен на Хабре релиз первой стабильной версии GO 1.

Именно на этот вопрос я хочу ответить циклом статей, оформленных в необычном для Хабра формате — в виде пошаговой совместной разработки действующего веб-проекта — с живым обсуждением и добавлением функционала. А чтобы вдвойне оправдать внесение цикла ещё и в хаб «Высокая производительность», мы поставим перед собой задачу создать не просто «хомяка», а проект, который наглядно продемонстрирует habri et orbi способность выдерживать значительные естественные нагрузки.

Вместо аперитива: реализация простейшего динамического веб-приложения на языке Go работает в 5-20 раз быстрее аналогичной Python-реализации. И всего в два раза уступает скорости отдачи статики Nginx-ом.

В рамках этого проекта, помимо самого языка Go, мы косвенно затронем и другие (относительно новые) технологии веб-разработки — HTML5, CSS3, Redis, MongoDB. Также я постараюсь вытащить из закутков долговременной памяти некоторые из трюков в области безопасности и экономии на спичках, коих накопилось много за полтора десятка лет работы в этой области. Устраивайтесь поудобнее, запасайтесь терпением и кофе — под катом «много букв», а ведь это только вводная часть :)

Чуть больше года назад я публиковал здесь на хабре скринкасты. Недавно вышел последний и хотелось поделится опытом создания скринкастов под линуксом.

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

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

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

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

При правильном подходе разработка новой функциональности может происходить довольно быстро и фокус тут в том, как не сломать при этом то, что было сделано раньше или же быстро понять, что именно ты сломал, и быстро это исправить. Каждый раз тестировать все детали и нюансы вручную очень долго и неэффективно, ведь в Эльбе сегодня уже более 400 «экранов». И проблема не только в том, что тестеры должны все это проверить вручную — очень много времени уходит на сценарий «тестер добавил баг — разработчик исправил баг — тестер проверил и закрыл/переоткрыл баг». Можно долго рассуждать о том, как трудно сохранить быстрорастущую систему в стабильном состоянии, почему код превращается в гавно, почему страшно делать исправления и никто не берет на себя смелость сказать дату релиза даже с точностью до месяца (потому что это было бы безответственно), но гораздо интереснее узнать о том, как сделать так, чтобы было хорошо.

Нам в Эльбе довольно часто задают вопросы по типу «Я „упрощёнщик“, у меня есть электронный кошелёк в Яндекс.Деньгах, как его в доходах-расходах учитывать и перед налоговой отчитаться?».

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