• Топ 20 навигационных фич в IntelliJ IDEA. Часть 2
    0
    Это легко сделать в IntelliJ IDEA с командой Recently Edited Files (Последние отредактированные файлы), назначенной на Ctrl + Shift + E (Cmd + Shift + E для OS X):

    В новых версиях (вроде с 2019.1), это уже так не работает. Теперь, чтобы перейти на список последних отредактированных файлов, надо нажать Cmd + E (откроется список недавних файлов) и еще раз Cmd + E (чтобы показать только измененные файлы).

    Cmd + Shift + E же, теперь, открывает новый и довольно полезный диалог Recent Locations, который тоже может быть отфильтрован, чтобы показывать только изменения (если нажать еще раз Cmd + Shift + E), и показывает не только название каждого файла, но еще и кусочек кода.
  • Опыт переезда для работы программистом в Берлин (часть 1)
    0
    Я не говорю что Германия не угодила в экономическом плане. Я говорю лишь что для айтишников, экономической целесообразности в переезде нет.

    В Питере можно работать удаленно на каких-нибудь американцев со скромным рейтом 30$/h и это выйдет около 300к рублей.
  • Опыт переезда для работы программистом в Берлин (часть 1)
    0
    Да, тут мы друг друга недопоняли. Я изначально отвечал на этот вот комментарий:
    Есть экономическая целесообразность такого переезда? За сколько лет можно социализироваться (машина, квартира) при зарплате 50к, например? Сколько в Берлине стоят продукты? Пассат? Квартира, коммуналка?
    Почему немцы сдают жилье на месяцы своего отъезда? Жмотятся или плохо живут?

    Отсюда и взялась зарплата в 50к и разговор исключительно об экономической составляющей. И да, я бы на 50к с женой и двумя детьми не поехал.
    «Денег у нас стало меньше, а уровень жизни стал выше»
    Согласны с этим тезисом?

    Абсолютно. У меня то же самое.
  • Опыт переезда для работы программистом в Берлин (часть 1)
    0
    С вами удивительно трудно вести беседу — вы постоянно передергиваете. Я не говорил, что где-то нашел 230к чистыми да еще и для мидла, не надо придумывать. Я даже и не искал. Я сказал лишь что 230 для Питера не выглядит как фантастическая зарплата. Да, это явно не зарплата мидла, но для сеньора вполне реальная, особенно фрилансера. А главное, что в Питере все (или почти все) значительно дешевле (в т.ч. жилье и машины — в 2 раза).
  • Опыт переезда для работы программистом в Берлин (часть 1)
    +1
    Давайте внесем немножко ясности:

    1. Я свожу к экономической составляющей, потому что вопрос на который я изначально отвечал был исключительно про нее. В своем первом комментарии я уточнил, что экономическая составляющая для большинства моих знакомых (и меня) не являлась основной мотивацией для переезда.
    2. Я не говорил что 150 на интернет. Я сказал что 150 это интернет, телефоны и электричество. Интернет 40 + 2 мобильника по ~15 + электричество ~50, выходит 120 или чуть больше (если у обоих безлимит с LTE). По минимуму если брать ну будет 100 за все, никак не 25-50.
    3. На еду я написал включая хозтовары (мыло там всякое, шампуни, бытовая химия), назвав это все «продукты». У меня лично меньше 700 на это ну никак не получается, но, конечно всегда есть возможность сэкономить.
    4. С жильем и 2-мя детьми не все так просто. Двушку снять тяжело, большинство отказывают. Нормальные трешки не очень далеко от центра от 900 начинаются, насколько я видел когда последний раз смотрел

    Кстати, мы с вами начали работать в Берлине в один день =)
  • Опыт переезда для работы программистом в Берлин (часть 1)
    +1
    Ну мы же говорим не о гипотетической «европейской» зарплате, а о вполне конкретной — 50к в год. Что после вычета налогов будет примерно 2.8к в месяц (при неработающей жене). В пересчете на рубли выходит где-то 230к рублей в месяц, что не выглядит фантастически для Питера.

    А по расходам в Берлине будет около 1000 на жилье, 200 на дет. садик (для двоих), где-то 700-800 на продукты, 150 на интернет, телефоны и электричество, 162 — общественный транспорт на двоих (если покупать помесячно), еще хочется чтобы дети занимались спортом и музыкой — у меня на это выходит где-то еще 300, плюс обеды на работе где-то 150. Уже из зп ничего не остается. А еще надо одежду покупать и иногда ходить развлекаться, спортом заниматься, путешествовать и что-то откладывать.

    Правда еще 380 евро будет государство за 2-х детей доплачивать, так что прожить, наверное, все таки можно. Но все равно, я бы не сказал что это выглядит экономически привлекательно.
  • Опыт переезда для работы программистом в Берлин (часть 1)
    +1
    Как человек, переехавший 1.5 года назад в Берлин из Питера, могу сказать, что в данный момент, экономической целесообразности в переезде в Берлин нет вообще. Несмотря на то, что Берлин по европейским меркам очень дешевый город, по современным курсам тут все совсем не дешево. Продукты так же либо дороже, жилье гораздо дороже, коммуналка дорогая, немецкие машины в Германии стоят примерно в 2 раза дороже чем в России, общественный транспорт тоже очень дрогой. Я бы сказал что на 50к прожить с неработающей женой и 2 детьми было бы очень тяжело, если вообще реально.

    Из всех моих знакомых, никто не приехал в Берлин из экономических соображений. В основном люди едут ради опыта, спокойствия, социальной защищенности, безопасности и т.д.
  • Вышел релиз Rails 4.1. Некоторые тонкости переезда
    0
    Ну вот, по-моему, основная ценность как раз в том, что теперь есть официальный способ делать это без костылей. Раньше кто-то использовал Figaro, кто-то RailsConfig, кто-то свои yaml-ы, инициалайзеры и другие костыли. Нравится вам Figaro — используйте, никто не заставляет переходить. Но для тех кто начинает новый проект на рельсах, теперь на одну проблему меньше. На мой взляд, это хорошее нововведение, а никак не костыль.
  • Вышел релиз Rails 4.1. Некоторые тонкости переезда
    0
    Это официальный способ хранения конфируации теперь (в том числе секретных ключей, но не только). Вы смотрели на secrets.yml, который создается генератором нового приложения? Там по-умолчанию пробиты значения для test и development окружения, а для production берется из окружения (через ERB). Соответсвенно, когда разработчик берет код из репозитория, у него локально все сразу работает. При деплое тоже не надо создавать/линковать никаких файлов, достаточно выставить переменные окружения. Ну и при этом доступ к конфигурации из приложения через Rails.application.secrets. Вроде все удобно (если, конечно, в gitignore не добавлять).
  • Вышел релиз Rails 4.1. Некоторые тонкости переезда
    0
    Ну так для этого переменные окружения есть.
  • Вышел релиз Rails 4.1. Некоторые тонкости переезда
    0
    А зачем добавлять secrets.yml в gitignore? Как раз удобно иметь его в репозитории, чтобы избежать трюкачества при деплое. И генератор нового приложения в Rails 4.1, кстати, его в gitignore не добавляет.
  • Чем опасен rebase-2, или как rebase мешал баг искать
    0
    Да, именно так. Фича которая не вмещается в день работы разбивается на подфичи, которые интегрируются в мастер каждый день. Зачем? Ну плюсы такие же как у continous integration подхода в чего чистом виде — избежать больших и сложных мержей, которые часто приводят к ошибкам.

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

    Отлично, если это работает для вас. Я считаю, что идеального workflow не существует. Для нас работает наш, для вас — ваш. Это прекрасно. Кстати, вы таки используете merge или rebase?
  • Чем опасен rebase-2, или как rebase мешал баг искать
    0
    Именно поэтому мы и не любим долгие бранчи. Если бы Вася работал у нас, было бы 30 коммитов, но каждый в своем бранче. И subfeature-s попадали бы в мастер по мере готовности, а не когда готовы все 30.
  • Чем опасен rebase-2, или как rebase мешал баг искать
    +1
    Вася не правильно пользуется rebase-ом, значит нету продуманного workflow работы с git-ом (понятного разработчикам), значит виноват Антон.

    Мое мнение состоит в том, что нельзя просто взять и заменить merge на rebase, в надежде, что все будет как раньше, только с линейной историей. Rebase — это сложный инструмент, который переписывает историю. Поэтому для его безболезненного использования нужна какая-то стратегия, основанная на разумных ограничениях. У нас, например, это 3 простых правила:

    1. Squash коммитов перед мержем ребейзнутого бранча в мастер
    2. Фича бранчи мержатся в мастер не реже чем раз в день (гибрид постоянной интеграции и бранчевания)
    3. Никаких rebase-ов для запушенных данных

    При этом, правило номер 2 выполняется не всегда. Скажем, если мы берем контрактника на определенную задачу, то для него вполне нормально будет сидеть в своем фича бранче месяц, а потом выдать в мастер один коммит (в результате rebase+squash). Если что-то пойдет не так после попадания его работы в мастер, то и откатить его задачу целиком будет очень просто (поскольку это один коммит).

    Если бы Вася пользовался этими правилами (или даже только 1-м), то проблема, описанная в статье, не возникла бы.
  • Чем опасен rebase, или как получилось, что 2*3=5
    0
    Что значит «как раз»? Этот пример и был изначально. «Патч» устарел, именно поэтому и делается rebase. После этого (если тесты проходят), о какой еще доработке идет речь? Да, возможно, будет ревью, но такая ошибка легко может быть не замечена при ревью и попадет в мастер.
  • Чем опасен rebase, или как получилось, что 2*3=5
    0
    На мой взгляд, вы торопитесь с выводами, говоря что тут rebase притянут за уши, и что мы им не правильно пользуемся. Описанный мной сценарий довольно популярен, и является рекомендованным, например, при разработке Ruby on Rails.

    Если представить, что оба разработчика из моего примера не являются core members и не могут пушить в мастер, а только шлют пулл реквесты и при этом соблюдают рельсовый contribution guide, то именно так в жизни это и будет выглядеть. Шаги 4 и 7 будут выполнены через пулл реквесты.

    Посмотрите, пожалуйста, внимательнее. Тут совсем не «Все что вы делаете это переносите патч в другую ветку». Тут классическая история, когда во время разработки feature2, мастер (естественно) ушел вперед. Поэтому чтобы влить feature2 назад в master, мы делаем сначала rebase, тем самым записывая изменения произведенные в feature2 поверх уже нового мастера. После этого шлем pull request (ну или мержим feature2 в мастер сами).
  • Чем опасен rebase, или как получилось, что 2*3=5
    +1
    Прочитал выше — не понимаю, что конкретно не корректно. Я специально проверил прежде чем писать комментарий. Все получилось как у автора, конфликта при rebase не было, а ошибка в итоге появилась. Пробовал именно такой сценарий, который используеся у нас (и не только, он довольно стандартен). Опишу подробнее по шагам, чтобы прояснить:

    1. Есть master в котором есть файл с таким содержимым:

    сумма
    2
    и
    2
    равна
    4

    2. Есть 2 разработчика, каждый создает свой бранч (feature1, feature2)
    3. В feature1 вносится изменение: слово «сумма» меняется на «произведение». Коммитит.
    4. feature1 мержится в мастер (не важно через pull request или нет)
    5. В feature2, другой разработчик меняет «2» и «4» на «3» и «5» соответсвенно. (У него по-прежнему «сумма», а не «произведение», потому код верный). Коммитит.
    6. В feature2 делается git rebase master. Тут rebase проходит автоматически, конфликта НЕ возникает, в коде появляется ошибка, как описал автор.
    7. feature2 мержится в мастер. В результате ошибка оказывается в мастере.

    Еще раз хочу отметить, что при merge ошибка точно также возникнет. Но как справедливо заметил автор, по истории git-а в случае merge будет легче разобраться как и почему так получилось. Вроде об этом и статья.
  • Чем опасен rebase, или как получилось, что 2*3=5
    +2
    Спасибо автору за хороший пример. Хочу еще раз отметить, что ошибка возникает и в том и другом случае, просто в случае с rebase сложнее понять историю и контекст ее внесения.

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

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

    У нас в проекте сейчас используется стратегия rebase (+squash), что позволяет держать историю коммитов красивой, компактной и почти линейной. Проект не очень большой, и ошибки такого рода у нас возникают очень редко (если вообще возникают), благодаря изолированности изменений (как правило разные разработчики редко правят одни и те же файлы) и тестам. Ну а если вдруг возникают — то у нас это не повод кого-то увольнять, а повод покрыть этот код тестом и исправить ошибку. Причина появления ошибки вторична.

    Выбор, конечно, должен быть осознанным. Но ведь как чертовски хорошо, что Git нам дает право на этот выбор!

    Ваш КО.
  • Ruby на вашем сервере может работать в 2 раза медленее из-за RVM
    +1
    Gist для rbenv + ruby-build. Одной командой ставит ruby-1.9.3-p327 с всевозможными performance патчами.
  • Простой, но показательный пример использования TDD
    0
    Сори, не совсем туда ответил
  • Простой, но показательный пример использования TDD
    0
    Да я топик особо не читал. Так, увидел начинающийся срач в комментах и решил вписаться.

    Если серьезно, я не берусь вас рассуждать, просто выскажу свое мнение: BDD тут и не пахнет. Однако, не все так просто. На мой взгляд, на таких синтетических примерах нельзя однозначно ничего утверждать. Тут можно слишком многое домыслить. Например, если предположить, что автор — единственное заинтересованное лицо (и будущий пользователь, заказчик), а система которую он разрабатывает — это один единственный юнит, то получается что это уже BDD по всем формальным признакам. Я бы даже сказал что при таких условиях, в этом частном случае TDD == BDD. Но это уже какая-то демагогия. А по существу я с вами согласен.
  • Простой, но показательный пример использования TDD
    0
    И да и нет. Просто сами понимаете, что на практике круг может быть не всегда круглым, и не совсем внешним. Например, может быть вообще только один круг, а может быть три круга или пять кругов. Это противоречит BDD или принципу outside-in? На мой взгляд это все условности. Поэтому может превратиться в TDD, может в недоBDD, а может вообще превратиться в новую методологию.

    А определение из книжки, которое вы привели, мне очень нравится: короткое, точное, емкое. А, главное, исходит от создателя(ей) BDD. Предлагаю сосредоточиться на нем, а не на условностях типа фреймворков и всяких там кругов. Фреймворки и круги просто позволяют на практике это быстро понять, попробовать и почуствовать.
  • Простой, но показательный пример использования TDD
    0
    Может я не правильно понял, но создалось такое ощущение по вашим предыдущим комментариям.

    С тем что вы сейчас говорите, я почти согласен. Но вот мне кажется, что не стоит завязывать внешний цикл на тестирование при помощи именно историй и Cucumber.

    Мне думается, это могут быть любые acceptance tests (для Руби — rspec, rspec + capybara/steak), описывающие высокоуровневые фичи (feature) в терминологии заказчика. Т.е. где название теста (плюс всякий сахар типа вложенности контекстов, сценариев и т.д.) как бы создает описание высокоуровневой фичи или целой пользовательской истории. Но, в моем понимании, BDD не требует того, чтобы бизнес аналитик мог читать (или еще хуже писать) код таких тестов (хотя, возможно, существуют и такие радикальные конфессии в BDD). Так как, по-моему, тут основная ценность в том, чтобы увидев, какие тесты внешнего круга падают, а какие работают, заказчик (или бизнес аналитик) мог понять, какие фичи в приложении реализованы, а какие нет. Т.е. чтобы вместо ошибки «падает какой-то ассерт в классе отправки почты», он видел что фича «Отправлять пользователю письмо с при регистрации» не работает. А как код такого теста реализован внутри (Cucumber или хоть читый RSpec), уже вторично.

    Поэтому я думаю, что BDD не перестанет быть BDD если вместо Cucumber для тестов внешнего круга использовать даже чистый RSpec. Главное, чтобы эти тесты действительно оставались тестами внешнего круга.

    PS: И, действительно, такие acceptance тесты очень похожи на интегральные тесты. Я бы даже сказал, что это что-то вроде интегральных тестов для заказчика (бизнес аналитика).
  • Простой, но показательный пример использования TDD
    0
    На мой взгляд, не корректно говорить, что BDD включает TDD. BDD — это скорее частный случай TDD, с особым стилем написания тестов, ориентированным на тестирование поведения. Написание спецификаций низкого уровня (те что аналогичны юнит тестам) на RSpec-е это тоже часть BDD, а вы называете это почему-то уже TDD.

    На картинке что вы приводили, изображены внешний и внутренний цикл BDD, использующиеся при подходе outside-in, применяемом в BDD. Вы пытаетесь выдать внешний цикл за BDD, а внутренний за TDD, но на самом деле, оба они представляют BDD. По большей части, я согласен с DarthSim, не понятно почему его комментарии минусуют.
  • Инструкция по ведению переговоров
    0
    Если кратко, то предлагается выставлять цену на 10-15% выше моей настоящей цены (первое предложение принимать не принято), а потом не идти на уступки (т.е. снижать цену можно только в обмен на уменьшения объема работ, например)? Т.е. другими словами, надо попытаться либо сразу вытянуть побольше денег, либо сделать за те же деньги, но меньше/хуже/медленнее. Или я чего-то не понял?
  • Слушаем музыку из Vkontakte через Амарок — V.2.0
    0
    посмотрите этот форк. Он далек от идеала, но я пользуюсь.
  • TrueCrypt 6.2
    0
    Полезно для мобильных дисков/ноутбуков. Например у меня переносной диск, зашифрованный трукриптом, который постоянно ношу с собой на работу. На нем личные документы, деловая переписка (почта-аська), финансовая отчетность, ключи от электронного банкинга и другая важная информация, которую хочется иметь под рукой и дома и на работе, и вообще где придется, но чтобы в случае потери/кражи диска никто ее не получил. В свое время выбрал трукрипт потому что бесплатный и кроссплатформенный, соответственно дома убунту, на работе раньше была винда и никаких проблем.
  • Многоядрёное программирование в .Net и нити.
    0
    А вы поток с процессом не попутали случайно?
  • Аддоны для Visual Studio
    +2
    Вообще встает. Но последняя стабильная версия (3.1) не поддерживает C# 3.0 (и VB 8 соответственно). Следующая версия (4.0), которая будет поддерживать все, сейчас в разработке - недавно вышла в статус беты.