Я думаю, что автор статьи на этот вопрос не ответит. Потому что иначе по шапке получат очень много людей за нецелевое использование материальных средств на разработку и внедрение непонятно чего :)
Это проходили много раз, и денег вбухано в разработку тоже огромное количество. Но увы, в традиционных финансах блокчейн не нужен, потому что по сути используется в качестве замещения обычной базы данных.
Когда мне было лет 14 я пытался открыть засохший тюбик, проткнул его иглой и мне в глаз брызнул суперклей. Не моргать не получилось рефлекторно, но я сразу же сунул глаз под струю воды из-под крана. Не знаю, смыл ли я всё.
В целом обошлось без последствий, зрение не потерял. Но первых пару дней хуже видел глазом и он слезился. А самое неприятное — это то что недели три при каждом моргании было ощущение что веко изнутри трут наждачной бумагой. Засыпать было тяжело, нужно было направлять глаз в определённую точку. Но постепенно прошло. С тех пор я в разумной степени параноик не только с пиротехникой, но и со всякой химией.
В этих компаниях, особенно небольших, есть одна проблема (натыкался сам, натыкались друзья и родственники): когда за год-полтора ты помимо своей основной работы тратишь кучу времени на собственное развитие и просишь адекватного увеличения з/п, то тебе отказывают, мотивируя это тем, что мол «мы тебя вырастили специалистом, работай мидлом за джуниорскую з/п». Ну и уходят из таких мест с повышением по деньгам в два раза.
Вспомнилось с моего прошлого места работы (почти так и было на самом деле):
Вы разбираетесь в технологии блокчейн?
Да, у нас есть в команде пара профильных специалистов.
Отлично, а то мы уже пообещали нашему новому заказчику «реализовать блокчейн» в его системе!
Простите, что? Там же фактически фронтэнд для Swift протокола, для чего там блокчейн?
Так вы же сказали, что у вас есть специалисты? Придумайте что-нибудь, у вас 3 дня для того чтобы сделать презентацию!
Ну ладно, так а что вообще ожидает заказчик от блокчейна, каким образом пересекаются задачи, которые решает его софт с задачами, которые решает блокчейн?
Вам виднее, выжпрограмиисты.
Т.е. ни вы (один из топ-ов) ни заказчик не знаете, что такое блокчейн и просите его использовать в софте заказчика, который вообще никаким боком к этой сфере?
Не знаю глобальной статистики, но те иностранцы которые приезжали к нам в командировки читали всё это с трудом (Германия, Индия, Израиль). Повторюсь — я больше не про расширенный алфавит, а про то с какого языка делается транслитерация.
Лично мне куда больше режет глаз когда названия станций транслитерируют с белорусского языка. Очень сложно понять иностранцев, которые пытаются произнести эти названия. А транслит, основанный на английском алфавите, с русских названий, вообще вопросов не вызывает.
По поводу карты — мне очень нравится.
Насколько я знаю, такой вход обусловлен объединением учёток из разных источников. В зависимости от формата логина используются разные авторизационые формы
Это нормально. У меня был собес, и вроде всё устраивало, про задачи интересные рассказывали. Но меня смутило то, что через стеклянные стены переговорки я у 2-х человек сидящих в оупен спейсе видел открытую Visual Studio 6. Решил уточнить, на какой версии с++ сопровождается проект. Когда выяснилось что это c++98 я вежливо попрощался. HR попыталась возразить, мол мы тут время на вас тратим, кофе вкусный сделали, на что я им посоветовал заранее указывать в вакансии стек технологий, чтобы адекватные люди не тратили свое время. Так как выборка кандидатов будет куда более релевантной.
Ну тут уже практически всё написали. Универсального рецепта не предложу, составьте свой список, пройдите пару-тройку собеседований и вы сами выставите приоритеты и поймёте, что стоит спрашивать, а что нет. И главное, у кого. Плюс я обязательно требую собеседования с будущим руководителем проекта, потому что зачастую от него получаешь 90% всей информации.
У меня есть опыт собеседований по обе стороны баррикад и базовые знания психологии. Плюс я интуитивно чувствую, когда люди врут. Иногда приходилось очень аккуратно выуживать детали, мол «у вас такие интересные условия работы, наверное низкая текучка кадров» и понимать, что что-то тут не то; а иногда слышал прямо «с вашим опытом и желанием развиваться вам будет скучно с нашим легаси на мфц, но если вы хотите денег, мы предложим вам х2 к желаемой вами сумме».
В целом вопросы технические: используемый стек технологий, методологии разработки, насколько реально, а не номинально получается следовать методологиям (это важно потому что часто люди работают по скрамбану и все шишки летят в разработчиков, вместо кривого менеджмента). Какое рабочее железо, политика касательно закупок софта, книжек и т.п. К примеру, мне нравится мой текущий проект, но объяснить своим менеджерам, которые потом будут объяснять заказчикам из google, зачем тебе нужен resharper проблематично, проще самому купить, благо зарплата позволяет.
Тщательно спрашиваю про бонусы и правила из начисления. Обычно всё сводится либо к интересным KPI (но рабочую схему видел лишь однажды), либо к «на усмотрение руководителя». Сам предпочитаю вариант, как наименее рискованный с точки зрения лояльности подчинённых, когда бонусов нет в принципе, за исключением каких-то критических ситуаций.
Отпуска (насколько заранее согласовывать), отгулы, переносы рабочих дней, в общем, насколько гибким является «гибкий график». Я увлекаюсь бальными танцами и после некоторых турниров чувствую себя как выжатый лимон, особенно если турнир заканчивается поздно в воскресенье. Максимум на что я буду способен в понедельник — листать почту/новости и ютубчик. Поэтому предпочитаю либо день отпуска, либо перенос рабочего времени. Хотя на нынешнем проекте ещё проще, никто не заморачивается.
При оценке работодателя надо стараться быть объективным. На нынешней работе меня вообще не могли проконсультировать по поводу проектов, т.к. я был первым с++ программистом в филиале компании, примерно месяц сидел on bench. Но остальные условия такие, что пока лучшего для себя в Минске я не встречал, хоть это и аутсорсинг.
Всегда спрашиваю, новая от вакансия, в связи с чем она открыта; и если не новая, то почему уволился предыдущий программист?
Ещё, когда заливают про карьерный рост и перспективы, можно вернуть hr на землю простым вопросом: кто за последний год в команде «вырос» и чём выражался этот рост? Аналогично про «гибкий график».
А вообще у меня всегда с собой в телефоне/на листике есть список вопросов (технических и организационных). Если в процессе собеседования на них я не получаю ответов, то задаю прямо.
Я понимаю, что вы процитировали типовой ответ первого уровня поддержки пользователей. А я, наивный, полагал что мне повезёт услышать честный ответ. Мол так и скажите — не прокатывает по юридическим причинам выложить Uber BY в глобальный стор. Могли бы выложить в глобальный и сделать заглушку для всех стран кроме РБ, к примеру. Так же как это реализовано в основном приложении. Ну реально, вы же сделали заведомо мёртвый usecase для иностранцев.
Единственный раз когда мне более менее честно ответили в поддержке, это когда я прислал видео с демонстрацией бага с расчётом стоимости поездки.
В 95% проектов, в которых я участвовал документация скорее даже мешала. Потому что не тратилось достаточно ресурсов на её ведение и документация как правило была сильно устаревшей. Только один раз был проект, делавшийся практически по канбану, где каждая задача включала обязательную разработку/обновление документации. И это делало практически бесплатным введение новых людей в проект.
Отладчиком пользоваться умею, впрочем как и читать код. Проблема в том что я слишком часто возвращаюсь к типичным мыслям юных разработчиков — переписать всё нафиг (хотя сисадминский опыт из детства кричит с другой стороны, что «работает, не трогай»). И начинаю часто отвлекаться на мелочи типа, вот тут надо по ссылке передать, а не shared_ptr плодить, вот тут сырые указатели, тут нет const, тут класс надо разбить на несколько, чтобы SOLID получился, там метод слишком длинный, сложный для отладки и т.п. Всё это в целом мешает главному — пониманию общей архитектуры проекта и уже более детальному пониманию каких-то узлов.
Немного не в тему, к сожалению достучаться через адреса техподдержки до людей, которые хоть что-то решают нереально.
Но очень хочется узнать, чем думал яндекс, когда делал приложение Uber BY (я так думаю, с Uber Russia аналогичная ситуация) доступным только из белорусского AppStore? Теперь, когда ко мне приезжают иностранцы я не могу сказать «вызовите убер». Мне приходится надеятся на то, что человек не полениться заранее сменить свой регион в телефоне, скачать нужное приложение и только потом лететь в Беларусь. Зачем вся эта свистопляска, нужно было сразу сделать как в Германии — мол в РБ убера нет, качайте заранее альтернативы. Тем более что приложение Uber By смотрится как дешёвый скин к Яндекс.Такси (к тому же, с порезанным функционалом).
У меня такая проблема и я не знаю, как с ней бороться. Поэтому всегда стараюсь попадать на свежие проекты.
Может есть какие-то практики, которые позволят научиться читать и понимать чужой код?
Спасибо за замечание. Если честно, скопипастил с какой-то своей старой лабы. Сам уже очень давно не использовал синглтоны на практике. Думаю суть посыла автор понял.
Для code review есть замечательный сайт codereview.stackexchange.com. Хабр немного не для этого.
Про 3-й пункт, минимально вот так:
template < typename T >
class Singleton
{
public:
static T& instance()
{
static T inst;
return inst;
}
protected:
Singleton() {}
virtual ~Singleton() {}
private:
Singleton( const Singleton& ) = delete;
Singleton& operator=( const Singleton& ) = delete;
};
// Ну и использование:
class MyClass : public Singleton<MyClass>{ ...
По поводу высокой связанности, в Qt есть сигналы/слоты. Неплохой пример, правда под QtQuick/QML можно глянуть тут.
Но я бы на вашем месте намного больше парился насчёт понимания многопоточности. Прочитайте про atomic/volatile. Про оптимизации компиляторов и т.п.
С ходу, то что с телефона разглядел:
1) Косяки с многопоточностью. Если вы хотите останавливать поток по bool переменной, её нужно сделать atomic.
2) Куча синглтонов. Они не нужны в принципе, но если уж очень хочется, то сделайте их через базовый класс.
3) Какие-то ненужные обвёртки вокруг stl контейнеров, которые ничего не делают. Самописный QSettings.
4) GUI сильно связан с логикой.
Первый способ крайне опасный, если вы не пишите приложение чисто для себя. Привет sql инъекции. Допускаю, что вы код накидали чисто для примера, но в любом случае не стоит так делать.
Я думаю, что автор статьи на этот вопрос не ответит. Потому что иначе по шапке получат очень много людей за нецелевое использование материальных средств на разработку и внедрение непонятно чего :)
Это проходили много раз, и денег вбухано в разработку тоже огромное количество. Но увы, в традиционных финансах блокчейн не нужен, потому что по сути используется в качестве замещения обычной базы данных.
Когда мне было лет 14 я пытался открыть засохший тюбик, проткнул его иглой и мне в глаз брызнул суперклей. Не моргать не получилось рефлекторно, но я сразу же сунул глаз под струю воды из-под крана. Не знаю, смыл ли я всё.
В целом обошлось без последствий, зрение не потерял. Но первых пару дней хуже видел глазом и он слезился. А самое неприятное — это то что недели три при каждом моргании было ощущение что веко изнутри трут наждачной бумагой. Засыпать было тяжело, нужно было направлять глаз в определённую точку. Но постепенно прошло. С тех пор я в разумной степени параноик не только с пиротехникой, но и со всякой химией.
В этих компаниях, особенно небольших, есть одна проблема (натыкался сам, натыкались друзья и родственники): когда за год-полтора ты помимо своей основной работы тратишь кучу времени на собственное развитие и просишь адекватного увеличения з/п, то тебе отказывают, мотивируя это тем, что мол «мы тебя вырастили специалистом, работай мидлом за джуниорскую з/п». Ну и уходят из таких мест с повышением по деньгам в два раза.
Вспомнилось с моего прошлого места работы (почти так и было на самом деле):
Не знаю глобальной статистики, но те иностранцы которые приезжали к нам в командировки читали всё это с трудом (Германия, Индия, Израиль). Повторюсь — я больше не про расширенный алфавит, а про то с какого языка делается транслитерация.
Лично мне куда больше режет глаз когда названия станций транслитерируют с белорусского языка. Очень сложно понять иностранцев, которые пытаются произнести эти названия. А транслит, основанный на английском алфавите, с русских названий, вообще вопросов не вызывает.
По поводу карты — мне очень нравится.
Насколько я знаю, такой вход обусловлен объединением учёток из разных источников. В зависимости от формата логина используются разные авторизационые формы
Это нормально. У меня был собес, и вроде всё устраивало, про задачи интересные рассказывали. Но меня смутило то, что через стеклянные стены переговорки я у 2-х человек сидящих в оупен спейсе видел открытую Visual Studio 6. Решил уточнить, на какой версии с++ сопровождается проект. Когда выяснилось что это c++98 я вежливо попрощался. HR попыталась возразить, мол мы тут время на вас тратим, кофе вкусный сделали, на что я им посоветовал заранее указывать в вакансии стек технологий, чтобы адекватные люди не тратили свое время. Так как выборка кандидатов будет куда более релевантной.
Ну тут уже практически всё написали. Универсального рецепта не предложу, составьте свой список, пройдите пару-тройку собеседований и вы сами выставите приоритеты и поймёте, что стоит спрашивать, а что нет. И главное, у кого. Плюс я обязательно требую собеседования с будущим руководителем проекта, потому что зачастую от него получаешь 90% всей информации.
У меня есть опыт собеседований по обе стороны баррикад и базовые знания психологии. Плюс я интуитивно чувствую, когда люди врут. Иногда приходилось очень аккуратно выуживать детали, мол «у вас такие интересные условия работы, наверное низкая текучка кадров» и понимать, что что-то тут не то; а иногда слышал прямо «с вашим опытом и желанием развиваться вам будет скучно с нашим легаси на мфц, но если вы хотите денег, мы предложим вам х2 к желаемой вами сумме».
В целом вопросы технические: используемый стек технологий, методологии разработки, насколько реально, а не номинально получается следовать методологиям (это важно потому что часто люди работают по скрамбану и все шишки летят в разработчиков, вместо кривого менеджмента). Какое рабочее железо, политика касательно закупок софта, книжек и т.п. К примеру, мне нравится мой текущий проект, но объяснить своим менеджерам, которые потом будут объяснять заказчикам из google, зачем тебе нужен resharper проблематично, проще самому купить, благо зарплата позволяет.
Тщательно спрашиваю про бонусы и правила из начисления. Обычно всё сводится либо к интересным KPI (но рабочую схему видел лишь однажды), либо к «на усмотрение руководителя». Сам предпочитаю вариант, как наименее рискованный с точки зрения лояльности подчинённых, когда бонусов нет в принципе, за исключением каких-то критических ситуаций.
Отпуска (насколько заранее согласовывать), отгулы, переносы рабочих дней, в общем, насколько гибким является «гибкий график». Я увлекаюсь бальными танцами и после некоторых турниров чувствую себя как выжатый лимон, особенно если турнир заканчивается поздно в воскресенье. Максимум на что я буду способен в понедельник — листать почту/новости и ютубчик. Поэтому предпочитаю либо день отпуска, либо перенос рабочего времени. Хотя на нынешнем проекте ещё проще, никто не заморачивается.
При оценке работодателя надо стараться быть объективным. На нынешней работе меня вообще не могли проконсультировать по поводу проектов, т.к. я был первым с++ программистом в филиале компании, примерно месяц сидел on bench. Но остальные условия такие, что пока лучшего для себя в Минске я не встречал, хоть это и аутсорсинг.
Всегда спрашиваю, новая от вакансия, в связи с чем она открыта; и если не новая, то почему уволился предыдущий программист?
Ещё, когда заливают про карьерный рост и перспективы, можно вернуть hr на землю простым вопросом: кто за последний год в команде «вырос» и чём выражался этот рост? Аналогично про «гибкий график».
А вообще у меня всегда с собой в телефоне/на листике есть список вопросов (технических и организационных). Если в процессе собеседования на них я не получаю ответов, то задаю прямо.
И да, главный вопрос: зачем нужно это приложение в принципе? С учётом того, что его полностью заменяет или даже значительно превосходит Яндекс.Такси.
Я понимаю, что вы процитировали типовой ответ первого уровня поддержки пользователей. А я, наивный, полагал что мне повезёт услышать честный ответ. Мол так и скажите — не прокатывает по юридическим причинам выложить Uber BY в глобальный стор. Могли бы выложить в глобальный и сделать заглушку для всех стран кроме РБ, к примеру. Так же как это реализовано в основном приложении. Ну реально, вы же сделали заведомо мёртвый usecase для иностранцев.
Единственный раз когда мне более менее честно ответили в поддержке, это когда я прислал видео с демонстрацией бага с расчётом стоимости поездки.
В 95% проектов, в которых я участвовал документация скорее даже мешала. Потому что не тратилось достаточно ресурсов на её ведение и документация как правило была сильно устаревшей. Только один раз был проект, делавшийся практически по канбану, где каждая задача включала обязательную разработку/обновление документации. И это делало практически бесплатным введение новых людей в проект.
Отладчиком пользоваться умею, впрочем как и читать код. Проблема в том что я слишком часто возвращаюсь к типичным мыслям юных разработчиков — переписать всё нафиг (хотя сисадминский опыт из детства кричит с другой стороны, что «работает, не трогай»). И начинаю часто отвлекаться на мелочи типа, вот тут надо по ссылке передать, а не shared_ptr плодить, вот тут сырые указатели, тут нет const, тут класс надо разбить на несколько, чтобы SOLID получился, там метод слишком длинный, сложный для отладки и т.п. Всё это в целом мешает главному — пониманию общей архитектуры проекта и уже более детальному пониманию каких-то узлов.
Немного не в тему, к сожалению достучаться через адреса техподдержки до людей, которые хоть что-то решают нереально.
Но очень хочется узнать, чем думал яндекс, когда делал приложение Uber BY (я так думаю, с Uber Russia аналогичная ситуация) доступным только из белорусского AppStore? Теперь, когда ко мне приезжают иностранцы я не могу сказать «вызовите убер». Мне приходится надеятся на то, что человек не полениться заранее сменить свой регион в телефоне, скачать нужное приложение и только потом лететь в Беларусь. Зачем вся эта свистопляска, нужно было сразу сделать как в Германии — мол в РБ убера нет, качайте заранее альтернативы. Тем более что приложение Uber By смотрится как дешёвый скин к Яндекс.Такси (к тому же, с порезанным функционалом).
У меня такая проблема и я не знаю, как с ней бороться. Поэтому всегда стараюсь попадать на свежие проекты.
Может есть какие-то практики, которые позволят научиться читать и понимать чужой код?
Извините за оффтопик, но вы очень наивны и слишком верите вашим СМИ.
Спасибо за замечание. Если честно, скопипастил с какой-то своей старой лабы. Сам уже очень давно не использовал синглтоны на практике. Думаю суть посыла автор понял.
Про 3-й пункт, минимально вот так:
По поводу высокой связанности, в Qt есть сигналы/слоты. Неплохой пример, правда под QtQuick/QML можно глянуть тут.
Но я бы на вашем месте намного больше парился насчёт понимания многопоточности. Прочитайте про atomic/volatile. Про оптимизации компиляторов и т.п.
С ходу, то что с телефона разглядел:
1) Косяки с многопоточностью. Если вы хотите останавливать поток по bool переменной, её нужно сделать atomic.
2) Куча синглтонов. Они не нужны в принципе, но если уж очень хочется, то сделайте их через базовый класс.
3) Какие-то ненужные обвёртки вокруг stl контейнеров, которые ничего не делают. Самописный QSettings.
4) GUI сильно связан с логикой.
Первый способ крайне опасный, если вы не пишите приложение чисто для себя. Привет sql инъекции. Допускаю, что вы код накидали чисто для примера, но в любом случае не стоит так делать.