> Многие водители считают что там уходят две полосы
Разметка ведь намекает учащенным штрихом, что полоса уйдет, плюс указатель стоит за 0.1 мили (~5 секунд на разрешенной скорости) до разделения полос, и еще есть 0.2 мили до самого отбойника.
Другое дело, что эта левая полоса более свободная, и многие по ней пытаются обогнать, а потом перед отбойником резко перестроиться вправо. Из-за этого те, кто едут по второй полосе, разумно притормаживают, чем опять же провоцируют обгоны по левой полосе.
Не знаю про Go, а вот C# в Долине непопулярен, в том числе и в FB. Если есть только такой опыт, то на собеседование еще могут позвать, но работать нужно будет с другим стеком.
Все написано правильно, только добавлю, что авария была часов в 10-11, а по этим полосам можно ездить всем без ограничений с 9 утра до 3 дня. В это время там движение конечно быстрее, но разница в скорости не настолько велика, как в часы пик.
В последний раз когда искал работу делал так: искал в интересующих компаниях людей, которым я могу отправить запрос на добавление (у меня в LinkedIn бесплатный аккаунт, а значит могу не всем) и отправлял этот запрос с просьбой порекомендовать меня в их компании. Естественно в основном это были русскоязычные разработчики, но если никого найти не получалось, тогда сперва отправлял запросы рекрутерам из этой же компании, после чего потенциальных контактов оттуда становилось в разы больше. Не скажу, что это сильно помогло, да и не все нормально отнесутся к такому спаму, однако пару рекомендаций удалось через это получить. Для больших компаний это лучше работает, а в маленькой шансы переехать по рабочей визе все равно невысоки (мне проще, т.к. я уже тут).
Лично я не считаю это чем-то некорректным, если человек не хочет отвечать/рекомендовать, у него всегда есть такая возможность. За успешную рекомендацию во многих компаниях выплачивают бонус, неуспешная вообще ничем не грозит. Разве что некоторые компании разрешают рекомендовать только бывших коллег (уж не знаю как они это проверяют, если вы работали вместе в другой стране/удаленно). А рекрутеры обычно сами добавляют всех без разбору.
От дома до офиса 12 миль гугл показывает, трачу 45-60 минут туда и столько-же обратно (Редвуд Сити до Маунт Вью).
Мой commute чуть длиннее (16 миль), но в другом направлении — 35 минут в час пик, а если позже на час, то и 20-30 минут.
Если у вас такие налоги, видимо вы живете один? В чем тогда проблема переехать поближе к офису (ну или найти работу ближе к дому)? В Mountain View или Sunnyvale можно за эту же цену найти нормальное жилье и тратить на дорогу 10 минут (или 20 на велике).
Покупать дорого, да, но ипотека вполне реальна.
Не очень понятно, а где же лучше жить, чтобы и до лесов, озер и гор было полчаса, и рестораны были и по ночам работали, и до офиса было пешком 15 минут, и работу было легко искать? Тот же вопрос и к автору, неужели в Питере с этим всем лучше (было тогда), что он так манил?
Не совсем понял. Как можно без установленного GitHub Extension в VS создать Pull Request на GitHub или открыть его в браузере?
Или речь идет о Pull Request для VSTS/TFS? Но оно, если не ошибаюсь, доступно только в VS Enterprise и не работает с GitHub.
Делали что-то такое в навигации Appercode, но там, конечно, вся эта навигация гвоздями прибита и все попроще. Cicerone — это более гибкое решение и мне это нравится.
Библиотека включает в себя необходимый минимум, если стараться учесть все кейсы, то маленькое решение превратится в гигантского монстра!
Все верно. Просто по моему мнению, вместо команды Replace хорошо бы иметь что-то вроде RemoveBackScreen. Библиотека останется маленькой, но станет более гибкой.
нативный софт всегда предпочтительнее кросс-платформенного при разработке
Если бы так и было, то у Xamarin не появилось бы столько клиентов (еще до сделки с Microsoft), Facebook бы не стали делать React Native, идея писать backend на JavaScript казалась бы всем безумной, а Java не существовала бы как платформа.
Очевидно, что если кто-то использует какой-то инструмент/стек, он ожидает, что плюсы перевесят минусы в его случае. Если он использует это не в первый раз, значит его ожидания оправдываются.
Конкретно мои критерии:
очень удобный, активно развивающийся и, при этом, стабильный язык,
Более того, большая часть функционала, приписываемая GitHub Extension на самом деле встроена в VS. Без установленного расширения, в VS вы не сможете только:
зарегистрироваться на GitHub;
создать репозиторий на GitHub (но можно создать локальный репозиторий, и сделать push в любой уже существующий удаленный);
сделать clone, выбрав репозиторий из списка (но можно сделать clone набрав/вставив URL);
быстро открыть в браузере страницы Pulse, Graphs, Issues, Wiki;
создать Pull Request на основе существующего branch (но сам branch создать можно);
быстро открыть существующий Pull Request в браузере.
В общем, расширение пока не дает чего-то особо полезного.
1) Да. Так можно решить, но хотелось бы избавиться от перехода назад к d. Мы ведь на самом деле не хотим его отображать. Кроме того, откуда нам знать, что там d? У нас нет ограничений на место откуда запущена аутентификация.
2) Не надо оставлять его в цепочке. Но убрать нужно уже после того, как он оказался в ее середине. Абстрактный пример (не очень хороший дизайн, просто для примера):
Зайти в профиль контакта
Зайти в группу контактов
Зайти в другой профиль
Зайти в группу контактов
...
Зайти опять в профиль контакта из пункта 1
Удалить контакт
Возвращаться назад до корневого экрана
При возврате в экран из пункта 1 показывать будет нечего (контакт уже удален). Хорошо бы удалить этот экран из цепочки сразу при удалении контакта.
Этих четырёх команд на практике достаточно для построения любых переходов
Не очень понятно что делать, если после успешной аунтефикации мне нужно переходить на новый экран, а не возвращаться на предыдущий? Или как запретить возвращаться на один из предыдущих экранов (не запрещая переход к корневому)? Команда типа RemoveBackScreen(String screenKey) могла бы решить обе эти задачи, а также с ней можно реализовать команду Replace.
Не совсем понял, выбор чего?
Почему Mac, а не Windows — мне и самому непонятно. Виртуализация или даже отдельная машина вполне доступны, но людям почему-то больше нравится работать в OS X.
Почему Xamarin, а не native — либо что-то упускаете, либо просто у вас был неудачный опыт с cross-platform.
Про разработку для Windows, я ничего не говорил. Вообще, разработку для десктопов тут не часто можно встретить.
Для меня это тоже было непонятно, пока не оказалось, что большинство разработчиков (да и вообще людей), которых я встречал в Silicon Valley, предпочитают Mac (да, выборка не репрезентативна). А при выборе стека для разработки чего-нибудь, варианты «от Microsoft» даже не рассматриваются, т.к. либо под Mac нет инструментов, либо что-то есть, но никто не в курсе. Конкретно в моей команде разработки под Android (на Xamarin, да) из ~5 человек на Windows сижу я один. Не удивительно, что Microsoft заинтересована в создании инструментов под Mac и продвижении своего стека среди тех, кто способен за это платить.
Какого порядка число таргетов? Демка — это тоже самое приложение с реализацией фичи/фикса или только сама фича?
Разметка ведь намекает учащенным штрихом, что полоса уйдет, плюс указатель стоит за 0.1 мили (~5 секунд на разрешенной скорости) до разделения полос, и еще есть 0.2 мили до самого отбойника.
Другое дело, что эта левая полоса более свободная, и многие по ней пытаются обогнать, а потом перед отбойником резко перестроиться вправо. Из-за этого те, кто едут по второй полосе, разумно притормаживают, чем опять же провоцируют обгоны по левой полосе.
Не знаю про Go, а вот C# в Долине непопулярен, в том числе и в FB. Если есть только такой опыт, то на собеседование еще могут позвать, но работать нужно будет с другим стеком.
В последний раз когда искал работу делал так: искал в интересующих компаниях людей, которым я могу отправить запрос на добавление (у меня в LinkedIn бесплатный аккаунт, а значит могу не всем) и отправлял этот запрос с просьбой порекомендовать меня в их компании. Естественно в основном это были русскоязычные разработчики, но если никого найти не получалось, тогда сперва отправлял запросы рекрутерам из этой же компании, после чего потенциальных контактов оттуда становилось в разы больше. Не скажу, что это сильно помогло, да и не все нормально отнесутся к такому спаму, однако пару рекомендаций удалось через это получить. Для больших компаний это лучше работает, а в маленькой шансы переехать по рабочей визе все равно невысоки (мне проще, т.к. я уже тут).
Лично я не считаю это чем-то некорректным, если человек не хочет отвечать/рекомендовать, у него всегда есть такая возможность. За успешную рекомендацию во многих компаниях выплачивают бонус, неуспешная вообще ничем не грозит. Разве что некоторые компании разрешают рекомендовать только бывших коллег (уж не знаю как они это проверяют, если вы работали вместе в другой стране/удаленно). А рекрутеры обычно сами добавляют всех без разбору.
Ну это сейчас, а в 2014 из всего этого были только театры с ресторанами.
А с поиском работы, если верить заголовку статьи, и сейчас нелегко.
Мой commute чуть длиннее (16 миль), но в другом направлении — 35 минут в час пик, а если позже на час, то и 20-30 минут.
Если у вас такие налоги, видимо вы живете один? В чем тогда проблема переехать поближе к офису (ну или найти работу ближе к дому)? В Mountain View или Sunnyvale можно за эту же цену найти нормальное жилье и тратить на дорогу 10 минут (или 20 на велике).
Покупать дорого, да, но ипотека вполне реальна.
Не очень понятно, а где же лучше жить, чтобы и до лесов, озер и гор было полчаса, и рестораны были и по ночам работали, и до офиса было пешком 15 минут, и работу было легко искать? Тот же вопрос и к автору, неужели в Питере с этим всем лучше (было тогда), что он так манил?
Но ведь, судя по подписи к вашему графику, это Skype.
Не совсем понял. Как можно без установленного GitHub Extension в VS создать Pull Request на GitHub или открыть его в браузере?
Или речь идет о Pull Request для VSTS/TFS? Но оно, если не ошибаюсь, доступно только в VS Enterprise и не работает с GitHub.
Делали что-то такое в навигации Appercode, но там, конечно, вся эта навигация гвоздями прибита и все попроще. Cicerone — это более гибкое решение и мне это нравится.
А как можно получить утечку памяти, если
Contextвсе равно живет всегда? Или речь идет обActivity, а не оContext.getApplicationContext?Все верно. Просто по моему мнению, вместо команды
Replaceхорошо бы иметь что-то вродеRemoveBackScreen. Библиотека останется маленькой, но станет более гибкой.Если бы так и было, то у Xamarin не появилось бы столько клиентов (еще до сделки с Microsoft), Facebook бы не стали делать React Native, идея писать backend на JavaScript казалась бы всем безумной, а Java не существовала бы как платформа.
Очевидно, что если кто-то использует какой-то инструмент/стек, он ожидает, что плюсы перевесят минусы в его случае. Если он использует это не в первый раз, значит его ожидания оправдываются.
Конкретно мои критерии:
Более того, большая часть функционала, приписываемая GitHub Extension на самом деле встроена в VS. Без установленного расширения, в VS вы не сможете только:
В общем, расширение пока не дает чего-то особо полезного.
1) Да. Так можно решить, но хотелось бы избавиться от перехода назад к
d. Мы ведь на самом деле не хотим его отображать. Кроме того, откуда нам знать, что тамd? У нас нет ограничений на место откуда запущена аутентификация.2) Не надо оставлять его в цепочке. Но убрать нужно уже после того, как он оказался в ее середине. Абстрактный пример (не очень хороший дизайн, просто для примера):
...
При возврате в экран из пункта 1 показывать будет нечего (контакт уже удален). Хорошо бы удалить этот экран из цепочки сразу при удалении контакта.
Не очень понятно что делать, если после успешной аунтефикации мне нужно переходить на новый экран, а не возвращаться на предыдущий? Или как запретить возвращаться на один из предыдущих экранов (не запрещая переход к корневому)? Команда типа
RemoveBackScreen(String screenKey)могла бы решить обе эти задачи, а также с ней можно реализовать командуReplace.Почему Mac, а не Windows — мне и самому непонятно. Виртуализация или даже отдельная машина вполне доступны, но людям почему-то больше нравится работать в OS X.
Почему Xamarin, а не native — либо что-то упускаете, либо просто у вас был неудачный опыт с cross-platform.
Про разработку для Windows, я ничего не говорил. Вообще, разработку для десктопов тут не часто можно встретить.