Предисловие или от куда взялась «бредовая» идея ставить Git на Windows

Я работаю в одной не очень большой IT-компании, которая продает свои и чужие программные решения, занимается проектами внедрения, оказывает клиентскую поддержку, проводит обучение и далее все такое в том же духе. До недавнего времени в моей маленькой команде разработки все было неплохо организовано и у нас даже был свой собственный достаточно мощный сервер. Но случилось непредвиденное и по воле злого рока один из серверов фирмы полетел, а руководство решило вместо него в стойку поставить наш сервер отдела разработки. Нам предложили «временно» переехать на любой из серверов общего назначения.

А теперь внимание! Только мы одни во всей фирме работаем на Линуксе, а все остальные сидят исключительно на Windows и сервера у нас тоже под управлением серверных редакций ОС от Билла Гейтса. И если перенос базы Redmine не вызывает особых вопросов, то задача поднять на сервере Windows сервер для Git меня сразу поставила в тупик. Но несколько часов потраченных на поиски дали мне простое работающее решение.

Сегодня я хочу поделиться своей методикой планирования времени в разработке ПО, которая может быть очень быстро внедрена в небольших коллективах. Она очень проста во внедрении и «поддержке», чем показала себя очень эффективной.В разное время, имея разные задачи и разные ограничения в управлении разработкой, я испробовал всё: от Microsoft Project и онлайн-сервисов до «самописных» решений. У каждого варианта есть свои недостатки и преимущества, и каждый из них заслуживает отдельной статьи. Сегодня речь пойдет о наиболее простом варианте — управление релизной разработкой в Excel-е. Также я поделюсь шаблоном этого плана, который каждый может доработать «под себя».

Со мной что-то не так. Ни в одном деле я не могу достигнуть высот мастерства. Будучи человеком увлекающимся, я чем только не увлекался (простите за тавтологию). И всё происходит по стандартной схеме:

Новая тематика -> Погружение с головой в вопрос -> Осознание границ тематики и собственных перспектив в ней -> Потеря интереса

Приветствую, уважаемые хабражители.

Мой опыт, которым я хочу с вами поделиться, должен оказаться полезным для всех пользователей ноутбуков, хотя мой частный пример — MacBook Pro.

После покупки сего агрегата, с порядковым номером в линейке: 6.1, я ожидал невиданных ранее скоростей, но, увы, предательская каруселька перегрузки, на месте курсора > появлялась достаточно часто, заставляла себя ждать, мучила вопросом «как так?!» при этом скорость загрузки тотально укомплектованной операционной системы составляла примерно 2+ минуты, с загрузкой 5-и приложений (различной тяжести) на автозапуске.

Такие показатели + периодические подвисания оказались досадным и обидным заключением, ведь под капотом процессор i7 / 4Gb DDR3 / 5 Series Chipset с возможной скоростью обмена данными в 3 гигабита.

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

Снова, привет!

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

Год назад я уволился из хорошей it-компании, проработав там 5 лет. Причины приводить не буду, чтобы не отвлекаться от темы. И оформив ИП, стал индивидуальным разработчиком (специально не говорю «фрилансер», т.к. не люблю это слово). За этот год я успел сделать некоторые выводы и сейчас делюсь ими с тобой (уточню, что буду вести речь исключительно об удаленной работе):

_{давным давно, в очень далёкой галактике…*
*ой, кажется, это уже где-то было…}

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

– В-владимир, – слегка заикаясь представился клиент. – В-вы тут с-сайты р-раз-рабатываете?

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

– Ну да, я. Александр. Чем-то могу быть полезным?

Я познакомился с Evernote лет пять назад, но первое время активно не использовал — у меня там были бессистемные блокноты для записи идей, документы, какие-то редкие фотографии, да и все. Задачи, которые я контролировал, хранил в Things, а контент — в Evernote. Примерно четыре года назад я начал формировать из контента личную базу знаний, раз в полгода её модифицируя. И вот уже как год я вношу только минорные изменения в структуру. Вот, что у меня получилось:

Всем привет! Мы продолжаем серию постов о том, как IT-фрилансеру стать предпринимателем. Вы уже знаете, почему ИП лучше, чем ООО и как зарегистрировать ИП самостоятельно. Сегодня мы расскажем, что ждёт предпринимателя после регистрации.



Краткий путеводитель для начинающих предпринимателей от «Я люблю ИП»

Этой весной, Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике я делаю перевод первого занятия. Если пост покажется стоящим — продолжу переводить и выкладывать.

Конспект лекций — Питер Тиль (курс: CS183) Стартап — Стэнфорд, весна 2012 г.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

Добрый день, уважаемые читатели.
Пролетели 2 недели и пришло время нашей подборки материалов по анализу данных. Сегодняшний дайджест получился большим, и признаюсь често сам осилил не все, что в него попало. Но так как на вкус и цвет товарище нет, то я решил выложить всю подборку.
Итак, из сегодняшней подборки вы узнаете о том как использовать хранилища данных различных типов в одном проекте, посмотрите какими большими данными может обладать бизнес и как их анализ может ему помочь. Также в нашей подборке будет статья посвященная алгоритму FTCA, а также будет материал про сравнени различных алгоритмов машинного обучения.

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

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

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

Методику составления рейтинга мы позаимствовали у Jurgen Appelo. Алгоритм подсчёта базируется на пяти различных критериях: количество отзывов Amazon, число отзывов GoodReads, средняя оценка Amazon, средняя оценка GoodReads, а количество дней, прошедших с первой публикации. Это означает, что этот список показывает вам смесь из самых популярных, лучших по оценкам, и (относительно) новейший книги в этой категории.

Данный список книг мы попросили прокомментировать двух экспертов:

Борис Вольфсон. Технический директор компании HeadHunter.

Андрей Ребров. Agile Engineering Coach компании ScrumTrek.

При таком сочетании – быстро, точно, без ТЗ – кажется, что задача не имеет решения. Однако в работе фрилансера такие задачи возникают постоянно, поэтому в борьбе за выживание заказы приходится учиться их решать. Для начала поясню, что означают вынесенные в заголовок слова.

Быстро – значит, раньше, чем заказчик примет решение о выборе исполнителя (другого исполнителя, раз вы еще не готовы ответить ему на самый главный вопрос).
Точно – значит, достаточно близко к реальной стоимости проекта, которую можно было бы озвучить после согласования ТЗ (а еще лучше после выполнения проекта, когда уже известно точное количество потраченного на разработку времени).
Ну и, наконец, что значит Без ТЗ? Понятно, что проектов совсем без ТЗ (в стиле «пойди туда, не знаю куда, принеси то, не знаю что») практически не бывает. Другое дело, в каком виде заказчик предоставляет вам это самое ТЗ.

Я хочу поделиться своим опытом использования MS Project для управления проектами по разработке программного обеспечения. Я уже лет 10 занимаюсь управлением проектами,
и в результате у меня родилась некоторая методология использования MS Project, которая позволяет получить от него немалую пользу и при этом меньше зависеть от его недостатков.

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Друзья, не знаю как вы, но мы не верим в быстродействующие таблетки. Мы не верим в «похудение за 2 недели на 40 кг». Черт побери, верить-то хочется, но реальность обычно против…

А тут целый PMBoK… Здоровенная такая штуковина, для больших и умных корпораций, а также неповоротливых гос.заказчиков… Как оказалось все не совсем. Для того, чтобы рассказать о чем-то сложном в понятной и доступной форме нужен практик, который разобрал вопрос до деталей, выделил главное, расставил акценты и прошелся по материалы с большим ярким маркером – читать тут, смотреть тут, применять вот так.

4 года назад менеджер по управлению проектами (PMI PMP), автор книги «Управление ИТ-проектом с нуля в любой организации» Иван Селиховкин выпустил бесплатный курс «Практический PMBoK за 5 дней», который на сегодня уже скачало более 7.000 человек. Однако, не так давно Иван пошел дальше и выпустил курс «Практический PMBoK за 2.5 часа» (доступен бесплатно после регистрации).

5 дней — я еще понимаю, но 2.5 часа — как-то того… отдает похуданием за 40 минут. :) Поскольку мы с Иваном давно сотрудничаем, то решили выяснить, как так получилось, что курс ужался с 5 дней до 2.5 часов. И начав говорить, поняли, что надо делать отдельное интервью. В итоге, обсудили массу тем:

• Как из медицины попасть в управление IT-проектами
• Почему последние годы процент успешных проектов не меняется
• Три шага на пути создания проектного офиса
• Что такое гос.заказчики геройские, бизнесовые и заурядные
• Есть ли противоречие между PMI и гибкими методологиями
• …

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

Я дизайнер интерфейсов. И я люблю мокапы.
Да и почему бы мне их не любить, если я только и делаю, что их делаю?

О прототипах или Называйте вещи своими именами

Для начала отметим, что мокапы и прототипы — отнюдь не одно и то же. В нерусском ИТ-словаре существуют несколько терминов для визуалов, соответствующих разным стадиям работы над ИТ-продуктом. Границы этих терминов размыты, но, тем не менее, увидев нечто интерфейсно-графическое, классифицировать его нетрудно.

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

Предисловие

Когда-то я хотел познакомиться с Rails поближе, но не знал с чего начать, пока мне на глаза не попалась эта статья. Далее вы увидите перевод, смешанный с собственным опытом и свойственными мне лексическими и фразеологическими оборотами. Итак, поехали.

Введение

У меня за спиной огромный опыт работы с PHP, но сейчас я работаю Rails разработчиком. Огромную сложность для большинства людей, которые пытаются освоить что-то новое — это сам процесс обучения. Когда вы владеете каким-либо языком или фреймворком и знаете его вдоль и поперёк, переход на что-то новое не представляется необходимым.

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

Последний раз я писал статью о проектировании в 2011 году. Тогда я собирался написать гораздо больше, но подумал: «Методика есть, но она не проверена временем, клиентами и проектами. Какого беса я буду писать о ней?». И не стал. Прошло два года, за которые мы с командой спроектировали полсотни разных проектов: корпоративные сайты и каталоги товаров, личные кабинеты, системы управления, сервисы, посадочные страницы, мобильные приложения. Многое поменялось: у меня есть статистика, данные по конверсии, отзывы пользователей и клиентов, сделано и исправлено много ошибок в методике и процессе. Теперь можно и написать.

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

Ниже несколько, во многом очевидных, тезисов, которые могут помочь новичкам в Scrum

Немного о проекте и о командах.

Описанный проект — первый, на котором мы решили применить Scrum в полной мере.
До этого работали по итерациям, но без Stand-up митингов, Ретроспектив и Демок.

Работы над проектом ведут две команды.

Команда 1 создает систему документооборота, в которой будут готовиться данные для некого приложения, которое разрабатывает Команда 2.

Из-за этого в определенных итерациях мы пересекаемся и сильно зависим друг от друга

Итак.