Я бы рекомендовал переехать в NYC в West Village - нет минусов долины (кроме климата): будет легко найти партнера (и не одного), большинство работает тут с перекосом в life balance при этом карьерные возможности не сильно хуже долины.
python: Jobs 1 to 10 of 44,996 php: Jobs 1 to 10 of 17,894
При этом много работы на PHP связано с drupal/wordpress/… или «full stack web developer» где надо все тот же javascript + css пилить и при этом оплачивается хуже чем более интересные (в среднем) и сложные задачи, которые обычно решают на python.
С алиасов гита перешел на алиасы из oh-my-zsh https://github.com/robbyrussell/oh-my-zsh/blob/master/plugins/git/git.plugin.zsh — очень рекомендую, хорошо продуманы. Заменили мне все комманды гита, которые я постоянно использую в работе, избавив меня от головной боли с продумыванием имен и подбором параметров для команд, когда я пытался сам сделать хорошую систему под себя.
В моем понимании это не архитектурное решение, а просто оптимизация памяти/скорости, при этом с усложнением дальнейшей поддержки кода.
Как раз 2 параллельных проекта сейчас, один с PDO, другой с Doctrine. Вроде PDO и быстрее, но поддержка похожего кода заметно усложнилась. В проекте с Doctrine и Symfony там где нужно что-то реально быстро сделать, это делают демоны на Go. Писать их проще, чем plain php, а производительность в десятки-сотни раз лучше.
Если ты годами пилишь один проект в маленькой команде, то может и ОК. В реальности люди уходят/приходят, проекты меняются.
Из практики:
Получил недавно проект на plain php — неделька нужна только чтобы вникнуть в идеи, которые автор закладывал при проектировании приложения. При очередном коммите реально боишься сломать что-то, серьезно что-то поменять в архитектуре не поломав половину просто нереально.
Получил в наследство проект на Yii2 — пару дней на погружение, и то, потому что автор много уходил он стандартов, описанных в документации.
Получил в наследство проект на Symfony — пол дня понадобилось чтобы войти в проект и делать реальные задачи.
Рельсы нравятся всем, но для меня сильно портит картину отсутствие такой же удобной IDE как для фреймворков из мира java/php/python. Из-за метапрограммирования тот же работающий в 100% случаев автокомплит сделать просто нереально. В основном по работе имею дело с Symfony и в документацию/stackoverflow лезу раз в неделю максимум: go to definition + автокомплит работают почти идеально (я говорю про PhpStorm + плагин Symfony), в запутанных случаях выручит xdebug. Я всегда смогу найти, почему этот код работает именно так.
При работе с рельсами go to definition и автокомплит уже далеки от совершенства и читать доки и SO приходится в разы чаще. Помогает, но частично:
* Использование аннотаций
* Дебаг
* Rails console
Подскажите, как кто решает проблему поддержки Rails в IDE?
1) В этом запросе логика простая, но в сервисе уже появились несколько сложных запросов, которые активно используют стандартную библиотеку, а она в Go весьма богатая.
2) У нас 32 ядра в процессоре и когда прилетит одновременно 32 запроса их выполнение распределится по всем ядрам и суммарно выполнятся за те же ~40-50µs если конечно по логике приложения не нужен будет лок на запись или сборщик не начнет работу.
3) Скорость работы очень радует, тесты просто роута, возвращающего json были близки к ретурну nginx-а:
В моем случае Go отлично подошел для написания бэкенда с несложной логикой. В качестве веб-фреймворка используется gin, для сохранения/получения промежуточных данных key-value хранилище bolt. Если взять для примера запрос, для обработки данных которого использутеся простая логика из цикла с парой вложенных условий с сохранением состояния через mutex, на отдачу ответа уходит ~40-50µs.
Inherited Resources is no longer actively maintained… I suggest developers to make use of Rails' respond_with feature alongside the responders gem as a replacement to Inherited Resources.
Пункты 3 и 5 о чем вообще? Из опыта работы с другими языками программирования для меня это очевидное поведение. Просто для tucnak, исходя из его опыта, это непривычно.
Я бы рекомендовал переехать в NYC в West Village - нет минусов долины (кроме климата): будет легко найти партнера (и не одного), большинство работает тут с перекосом в life balance при этом карьерные возможности не сильно хуже долины.
Поделитесь компаниями, где 300-400к мидлы получают в Москве.
Только «забугорные» компании сразу выше рынка платят со старта www.levels.fyi/comp.html?track=Software%20Engineer
Google может меньше дать, но с контр-оффером сразу поднимают так же.
python: Jobs 1 to 10 of 44,996
php: Jobs 1 to 10 of 17,894
При этом много работы на PHP связано с drupal/wordpress/… или «full stack web developer» где надо все тот же javascript + css пилить и при этом оплачивается хуже чем более интересные (в среднем) и сложные задачи, которые обычно решают на python.
Как раз 2 параллельных проекта сейчас, один с PDO, другой с Doctrine. Вроде PDO и быстрее, но поддержка похожего кода заметно усложнилась. В проекте с Doctrine и Symfony там где нужно что-то реально быстро сделать, это делают демоны на Go. Писать их проще, чем plain php, а производительность в десятки-сотни раз лучше.
Если ты годами пилишь один проект в маленькой команде, то может и ОК. В реальности люди уходят/приходят, проекты меняются.
Из практики:
При работе с рельсами go to definition и автокомплит уже далеки от совершенства и читать доки и SO приходится в разы чаще. Помогает, но частично:
* Использование аннотаций
* Дебаг
* Rails console
Подскажите, как кто решает проблему поддержки Rails в IDE?
1) В этом запросе логика простая, но в сервисе уже появились несколько сложных запросов, которые активно используют стандартную библиотеку, а она в Go весьма богатая.
2) У нас 32 ядра в процессоре и когда прилетит одновременно 32 запроса их выполнение распределится по всем ядрам и суммарно выполнятся за те же ~40-50µs если конечно по логике приложения не нужен будет лок на запись или сборщик не начнет работу.
3) Скорость работы очень радует, тесты просто роута, возвращающего json были близки к ретурну nginx-а:
location /test_json { return 200 '{"message": "Hello, world!"}'; }Inherited Resources is no longer actively maintained… I suggest developers to make use of Rails' respond_with feature alongside the responders gem as a replacement to Inherited Resources.