Подкопите денег и приеприезжайте на 2 недели раньше, если боитесь именно акклиматизации ) Думаю, пары тысяч долларов хватит на оплату отеля, еды и транспорта на этот срок.
Пффф, да сколько угодно. У того же Вымпелкома с несколько десятков систем, на обсуждение каждой новой версии которой они тратят сильно больше, чем пол человеко/года. Как и у практически любой крупной компании. И почему-то у их исполнителей очень часто получается соблюдать сроки. Вы сейчас мыслите в масштабах фрилансера-одиночки, мир вокруг сильно больше и разнообразнее.
Вам неправильно кажется. В крупных интеграторах такое нередко бывает. Или в компаниях, которые продают крупный, но не совсем коробочный продукт типа CRM. На нижнем звене программисты заменяются легко благодаря чёткому ТЗ, мощной платформы, методологии и детально описанных документов с дизайном изменений.
Т.к. на разных проектах программисты работают, по сути, с одной и той же кодобазой, то замена нижнего звена программистов совсем проста, им совсем не надо «въезжать в код» — что и где менять написано в дизайне изменения, а как менять — они и сами знают. Замена людей, пишущих эти дизайны, требует небольшого лишь периода времени на ознакомление с ситуацией в конкретном проекте. Нелегко менять только тех людей, которые дают оценки по времени и решают в крупных мазках, где и что надо сделать для решения проблемы бизнеса заказчика, т.к. они обязаны хорошо знать конкретную систему этого заказчика.
Да, программирование в таких конторах — это скорее ремесло, чем искусство.
Я работал в компании, которая продавала заказчикам здоровенную систему (несколько миллионов строк кода), а затем регулярно делала новые версии, внося изменения по требованиям заказчика. Цикл сбор требований — их обсуждение — проектирование изменений — собственно из программирование — тестирование занимал год и при этом сроки чётко соблюдались. Да, waterfall. И, в пику рассуждениям автора, программисты там могли быть заменены почти безболезненно, потери времени минимальные благодаря чётко поставленному процессу и наличию большого количества программистов, работающих на соседнем похожем проекте.
Иногда мне кажется, что всякие agile техники популярны потому, что команда не понимает важности наличия аналитика, который вытащит из заказчика, что же он хочет на самом деле, нежелания зафиксировать эти самые желания и неумения оценивать сроки. Возможно, всё и не так на самом деле, но ощущение вот такое. И мне до сих пор не ясно, как команды, применяющие гибкие методологии, могут гарантировать поставку продукта до дедлайна.
Обычно подобные статьи являются научными работами или докладами на конференциях. У гугла есть целый сайт: research.google.com/. Регулярно подобные статьи появляются на highscalability.com/. И, конечно же, надо отлично знать сложность базовых алгоритмов и операций со структурами данных в О-нотации.
Задачи на собеседованиях обычно дают практического характера: как сделать top5 статей (и ответ «select * from… order by views limit 5 явно не подходит), как сделать новостную ленту типа фейсбучной, или как сохранить миллиард файликов. При этом обязательно надо понимать, какую производительность можно получить с диска и из памяти, на сколько хорошо параллелится задача при одновременных запросах от разных клиентов, и когда стоит записывать данные из памяти на диск.
Когда вы решаете задачу — надо мыслить на уровне алгоритмов и структур данных. Если вы отвечаете „а вот тут поставлю mongo/mysql/oracle/btrfs“ — почти наверняка последует вопрос „а почему именно это“ и „почему оно выдержит требуемые нагрузки“. Кстати, какие именно нагрузки будут — отдельный вопрос, который надо задавать интервьюеру, и в том числе и по подобным вопросам становится понятна квалификация собеседуемого.
Ну и отдельно стоит посмотреть задачки со всяких квалификационных раундов hacker cup и с собеседований, иногда там попадаются именно алгоритмические штуки. Можно почитать про штуки типа хэштаблицы локов, lock-free структуры или boost intrusive. Обязательно понимать, как могут синхронизироваться треды или процессы. В процессе использования готовых фреймворков-приложений-серверов пытаться понять, как именно они работают, и почему именно так.
Про DMCA уже упоминали в каментах, напомню только о законном рутките, который распространяла SONY на своих дисках в качестве DRM.
Далее, в начале 2012 года Обама говорил, что он против принятия SOPA. Осенью 2012 года состоялись выборы, гонка же началась аж за 1.5 года до выборов. Петицию подписали более 7 миллионов человек, как подсказывает мне википедия. А Обаме очень сильно были нужны голоса на предстоящих выборах.
Как думаете, какова вероятность принятия нового аналога SOPA в США, если смягчить его до российского законопроекта, да ещё и не перед выборами продвигать? Например OPEN, который продвигается Facebook и Google. Тем более, что в области борьбы за права (копирайт) и патенты США впереди планеты всей.
Что-то мне кажется, что SOPA или что либо подобное в штатах намного раньше введут. Просто вспомните, как быстро и лихо там ввели антитеррористические законы. Достаточно какой нибудь Apple, как одному из крупнейших игроков на рынке, поддержать подобный закон — его моментально введут, а пользователи ещё и рады будут.
Как и в США, где зарплаты в НЙ/Долине существенно выше, чем в среднем по стране. Скажем, 140к в год в Пало Альто вместо 60к где нибудь в Сент Луисе. Со всякими магазинами в мелких городках в штатах конечно получше, чем у нас, но скучно ужасно. В городе Понтиак сотрудики музеев практически набрасывались на нас, желая рассказать про свои экспонаты побольше :)
Вы немного неправильно меня поняли. У вас будет всего 2 файла: индексный, и файл с данными. В индексном файле хранится название песни и артиста со всякой прочей дополнительной информацией, смещение в файле с данными и длина собственно текста. Внутри файла с данными каждая песня по-отдельности упакована зипом. То есть это будет много маленьких архивчиков, и все они лежат в одном большом файле, чтобы не надо было файловую систему насиловать. Индексный файл, на сколько я понимаю, у вас уже готов — artists.bin, надо будет только добавить смещение+длину в класс Song.
Чтобы быстро переход работал — всасывать индексный файл со смещениями и длинами в память при старте, тогда чтение текста песни превращается в вычитывание небольшого кусочка файла по известному заранее смещению, длина кусочка тоже известна. Кажется, это должно работать очень быстро.
Какой примерно размер каждой песни? Попробуйте зазиповать каждый текст по-отдельности и склейте вместе, возможно получится не сильно больше и не надо будет распаковывать всё при первом старте. Если компрессия слишком маленькой получится — паковать по 10-20 штук, вычитывать и распаковываться будет всё так же быстро, а по объёму сильно выиграете.
Подумайте и докажите, что в предыдущих сообщениях я был прав. Поверьте, это значительно проще, чем пытаться защитить свою позицию.
Вот это свежее и неожиданное предложение :) Повторюсь, мне, как разработчику, было бы неприятно, если бы в интернетах написали про мою программу в негативном ключе, но специально не проинформировали меня с посылом: «ну у него же должно быть желание исправить свою программу и искать, что о программе пишут в интернетах». Ну и Яндекс != разработчик программы. Хотя тут скорее даже менеджер проекта должен прочитать, но я не уверен, что он есть у Я.Метро. Вы правда проделали хорошую работу и нашли некоторые баги, придумали новый, потенциально полезный функционал, но если бы ещё и подали её в правильном направлении…
Вы заблуждаетесь, не стоить верить всем комментариям, в которых написано, что другие думают. Прочитайте ещё раз статью и попробуйте процитировать хотя бы одно негативное высказывание в адрес компании Яндекс или её разработчиков.
Я говорю только про текст статьи. Я даже потружусь цитаты привести.
Недавно наткнулся на ошибку в Android приложении Яндекс.Метро. Если бы был чемпионкой мира по синхронному плаванию, то обязательно спросил бы: «Кто создавал программу „для галочки“? Кто работал „на отшибись“? Кто слабое звено?».
Но даже при отключённой функции «Сообщать о пробках» программа продолжает показывать текущее местонахождение (стандартная функция Android всё ещё выключена).
Прикрываясь с помощью «AS-IS» компании могут безответственно выпускать программные продукты любого качества. Разгильдяйство не наказывается пока «пипл хавает», можно делать всё «на отшибись»..
Достаточно «включить мозг» при разработке и тестировании, чтобы улучшить программный продукт.
Ну и само название статьи: «Думайте при разработке». Так как вся ваша статья посвящена разбору ошибок во вполне конкретной программе, то и все эти фразы относятся к разработчикам этой самой программы, правда ведь?
Что же касается времени. Если у пользователя стоит галочка автоматического получения времени — всё работает отлично. Если пользователь сам переводит часы в телефоне так, чтобы они показывали правильное локальное время — всё отлично. это покрывает абсолютное большинство кейсов.
Когда вы говорите, что моменты времени общие для всех — это так, UTC придумали именно для этого. Но при отсутствии интернета нет никакого способа узнать, совпадает ли UTC время в телефоне с временем UTC настоящего мира. И если пользователь переводит время в телефоне руками — то вероятность такого несовпадения сильно повышается. Судя по вашим ответам, вы не понимали этой проблемы. В итоге может получиться, что пользователь с правильным локальным временем на часах своего телефона (но с неправильной таймзоной, что его никак не беспокоит) будет получать от программы неправильный ответ. При наличии доступа в интернет можно попробовать исправить ситуацию, но это будет не 2 строчки кода.
Ещё одной проблемой вашего предложения является пользовательский опыт: сверху экрана на часах пользователь видит 06:30, локальное время действительно 06:30, а программа ему пишет: извините, метро ещё закрыто, открывается в 6:00. Возможно, если сделать специальные предупреждения о разницы во времени и часовых поясах, это будет допустимо.
А что с графом? В программе нет явных ошибок в данных по связям станций между собой. Обсуждения люблю, но фантазировать не всегда есть время. Если есть тема — поднимайте.
Вы же сами в статье написали
Программа отображает маршруты между двумя станциям, но наиболее очевидный (и короткий) не находит.
и почти половина статьи про это. Собственно, это и является проблемой с графом, а не алгоритмической ошибкой.
Останется только решить вопрос, как глаз будет фокусироваться на изображении, производимом этой «линзой». А вот применять такую штуку в очках со полупрозрачным стеклом очень даже можно, в качестве коллиматора обычную линзу френеля поставить — получится лёгкая и довольно компактная конструкция с хорошим разрешением.
Яндекс — большая компания, и если какой-то один работник увидел вашу статью — это не значит, что информация о ней попала к разработчикам. Тем более сотрудники оставляют комментарии как частные лица, их комментарии не считаются ответом от лица компании. Вы сами написали адрес формы службы поддержки — так сложно написать туда ссылку на статью? Тем более, что всё равно вы уже ушат помоев вылили, и заодно сказали, что разработчики яндекс.метро мозг не включали и не тестировали свой продукт, работали «на отшибись».
По второй части — это, простите, вы работаете «на отшибись». Вы написали большую статью про тестирование продукта, про необходимость изучения особых точек функционала, а потом пишете, что достаточно будет пары строк.
Начнём с простого:
Какова вероятность, что у пользователя не будет выставлена галочка «автоматически определять время через соторую сеть»?
Какова вероятность, что у пользователя, раз он выставляет время руками, правильно выставлена временная зона?
Какова вероятность, что у пользователя в принципе есть правильная таймзона? (Актуально для России, Белоруссии, Украины, и связано с летним-зимним временем)
Если таймзона указана не точно (UTC вместо GMT, или не стоит галочка о переходе на летнее-зимнее время, а переход должен быть), то как обрабатывать переходы с летнего на зимнее время и наоборот?
Что делать, если нету правильной целевой таймзоны?
Как понять, что пользователь уже перевёл часы, и при этом не менял таймзоны, то есть просто изменил время в настройках?
Достаточно ли будет 2 строчек кода решения всех возможных проблем? Мне кажется, что нет.
Вопрос посложнее:
Я отключаю интернет и, находясь в Москве, включаю карту метро Минска. Время надо переводить? А если я то же самое делаю находясь в Минске? Как определить, где я нахожусь, без интернета?
И это только технические вопросы. При этом самый главный вопрос для менеджера проекта — как часто пользователи Яндекс.Метро не переставляют время в телефоне, вручную или автоматически, уезжая в другую временную зону? Будет ли этот новый функционал неправильно переводить время и у какого процента пользователей?
Кстати, я на 90% уверен, что разработчики данной программы делают не «на отшибись», и очень стараются выпустить качественный продукт. Пожалуй, единственное, с чем можно безоговорочно согласиться в вашей статье — это то, что очень плохо, что в программе нету кнопки «сообщить об ошибке». Как повод для обсуждений — исходные данные графа о времени пересадок. Но вы обсуждения, очевидно, не хотите.
Вы сделали неправильно. Корректным было бы отправить разработчикам ссылку на эту статью. Вам же вряд ли бы захотелось, чтобы я поливал вас грязью в каком нибудь другом бложике, правда? Особенно если бы ещё в том, другом бложике, написал через пару дней: очевидно, автору статьи насрать на мнение окружающих, потому что он мои комментарии к своей статье в интернете не нашёл и не отреагировал. Глупо звучит, правда? Вы сейчас сделали то же самое. И не надо писать о том, что мол хабр все обязаны читать и т.д.
Кстати, вы когда про какие либо фичи пишете (типа попытки определения правильного текущего времени) — то подумайте, на сколько этот кейс популярен и сколько будет стоит их разработка и тестирование. Пока я видел не локальное время на телефоне только у людей, которые забыли его перевести, и при этом изначально ставили ручной перевод часов. Очевидно, что при ответе программы «а метро то уже закрыто» они бы часы перевели. Держать на телефоне московское время, находясь при этом в Минске — очень редкое развлечение.
Вы не совсем правы. Меня через HH нашла контора, которая делает суперкомпьютеры NUMA используя межпроцессорную шину AMD на обычных серверных материнках. Звали OpenBIOS пилить. Но тогда у меня уже было другое предложение и я от суперкомпьютеров отказался. Регулярно натыкаются там на моё резюме и зовут делать какие-то низкоуровневые штуки, связанные в вычислениями на видеокартах, но приходится пояснять, что это было всего лишь хобби и надо будет многому учиться :) Эйчары практически любой компании прежде всего туда идут, когда хотят найти работников в IT сфере.
Охладится, причём сильно. Потом, конечно, испарится, но в первые минуты будет именно лёд. Будете в Сан-Франциско — загляните там в Exploratorium, там собрали всякие штуки, которые обычно показывают на лекциях по физике, и всё можно пощупать. Возможно, в московском политехе тоже есть подобные штуки, я там был ооочень давно.
Т.к. на разных проектах программисты работают, по сути, с одной и той же кодобазой, то замена нижнего звена программистов совсем проста, им совсем не надо «въезжать в код» — что и где менять написано в дизайне изменения, а как менять — они и сами знают. Замена людей, пишущих эти дизайны, требует небольшого лишь периода времени на ознакомление с ситуацией в конкретном проекте. Нелегко менять только тех людей, которые дают оценки по времени и решают в крупных мазках, где и что надо сделать для решения проблемы бизнеса заказчика, т.к. они обязаны хорошо знать конкретную систему этого заказчика.
Да, программирование в таких конторах — это скорее ремесло, чем искусство.
Иногда мне кажется, что всякие agile техники популярны потому, что команда не понимает важности наличия аналитика, который вытащит из заказчика, что же он хочет на самом деле, нежелания зафиксировать эти самые желания и неумения оценивать сроки. Возможно, всё и не так на самом деле, но ощущение вот такое. И мне до сих пор не ясно, как команды, применяющие гибкие методологии, могут гарантировать поставку продукта до дедлайна.
Обычно подобные статьи являются научными работами или докладами на конференциях. У гугла есть целый сайт: research.google.com/. Регулярно подобные статьи появляются на highscalability.com/. И, конечно же, надо отлично знать сложность базовых алгоритмов и операций со структурами данных в О-нотации.
Задачи на собеседованиях обычно дают практического характера: как сделать top5 статей (и ответ «select * from… order by views limit 5 явно не подходит), как сделать новостную ленту типа фейсбучной, или как сохранить миллиард файликов. При этом обязательно надо понимать, какую производительность можно получить с диска и из памяти, на сколько хорошо параллелится задача при одновременных запросах от разных клиентов, и когда стоит записывать данные из памяти на диск.
Когда вы решаете задачу — надо мыслить на уровне алгоритмов и структур данных. Если вы отвечаете „а вот тут поставлю mongo/mysql/oracle/btrfs“ — почти наверняка последует вопрос „а почему именно это“ и „почему оно выдержит требуемые нагрузки“. Кстати, какие именно нагрузки будут — отдельный вопрос, который надо задавать интервьюеру, и в том числе и по подобным вопросам становится понятна квалификация собеседуемого.
Ну и отдельно стоит посмотреть задачки со всяких квалификационных раундов hacker cup и с собеседований, иногда там попадаются именно алгоритмические штуки. Можно почитать про штуки типа хэштаблицы локов, lock-free структуры или boost intrusive. Обязательно понимать, как могут синхронизироваться треды или процессы. В процессе использования готовых фреймворков-приложений-серверов пытаться понять, как именно они работают, и почему именно так.
Про DMCA уже упоминали в каментах, напомню только о законном рутките, который распространяла SONY на своих дисках в качестве DRM.
Далее, в начале 2012 года Обама говорил, что он против принятия SOPA. Осенью 2012 года состоялись выборы, гонка же началась аж за 1.5 года до выборов. Петицию подписали более 7 миллионов человек, как подсказывает мне википедия. А Обаме очень сильно были нужны голоса на предстоящих выборах.
Как думаете, какова вероятность принятия нового аналога SOPA в США, если смягчить его до российского законопроекта, да ещё и не перед выборами продвигать? Например OPEN, который продвигается Facebook и Google. Тем более, что в области борьбы за права (копирайт) и патенты США впереди планеты всей.
Чтобы быстро переход работал — всасывать индексный файл со смещениями и длинами в память при старте, тогда чтение текста песни превращается в вычитывание небольшого кусочка файла по известному заранее смещению, длина кусочка тоже известна. Кажется, это должно работать очень быстро.
Я говорю только про текст статьи. Я даже потружусь цитаты привести.
Ну и само название статьи: «Думайте при разработке». Так как вся ваша статья посвящена разбору ошибок во вполне конкретной программе, то и все эти фразы относятся к разработчикам этой самой программы, правда ведь?
Что же касается времени. Если у пользователя стоит галочка автоматического получения времени — всё работает отлично. Если пользователь сам переводит часы в телефоне так, чтобы они показывали правильное локальное время — всё отлично. это покрывает абсолютное большинство кейсов.
Когда вы говорите, что моменты времени общие для всех — это так, UTC придумали именно для этого. Но при отсутствии интернета нет никакого способа узнать, совпадает ли UTC время в телефоне с временем UTC настоящего мира. И если пользователь переводит время в телефоне руками — то вероятность такого несовпадения сильно повышается. Судя по вашим ответам, вы не понимали этой проблемы. В итоге может получиться, что пользователь с правильным локальным временем на часах своего телефона (но с неправильной таймзоной, что его никак не беспокоит) будет получать от программы неправильный ответ. При наличии доступа в интернет можно попробовать исправить ситуацию, но это будет не 2 строчки кода.
Ещё одной проблемой вашего предложения является пользовательский опыт: сверху экрана на часах пользователь видит 06:30, локальное время действительно 06:30, а программа ему пишет: извините, метро ещё закрыто, открывается в 6:00. Возможно, если сделать специальные предупреждения о разницы во времени и часовых поясах, это будет допустимо.
Вы же сами в статье написали
и почти половина статьи про это. Собственно, это и является проблемой с графом, а не алгоритмической ошибкой.
По второй части — это, простите, вы работаете «на отшибись». Вы написали большую статью про тестирование продукта, про необходимость изучения особых точек функционала, а потом пишете, что достаточно будет пары строк.
Начнём с простого:
Какова вероятность, что у пользователя не будет выставлена галочка «автоматически определять время через соторую сеть»?
Какова вероятность, что у пользователя, раз он выставляет время руками, правильно выставлена временная зона?
Какова вероятность, что у пользователя в принципе есть правильная таймзона? (Актуально для России, Белоруссии, Украины, и связано с летним-зимним временем)
Если таймзона указана не точно (UTC вместо GMT, или не стоит галочка о переходе на летнее-зимнее время, а переход должен быть), то как обрабатывать переходы с летнего на зимнее время и наоборот?
Что делать, если нету правильной целевой таймзоны?
Как понять, что пользователь уже перевёл часы, и при этом не менял таймзоны, то есть просто изменил время в настройках?
Достаточно ли будет 2 строчек кода решения всех возможных проблем? Мне кажется, что нет.
Вопрос посложнее:
Я отключаю интернет и, находясь в Москве, включаю карту метро Минска. Время надо переводить? А если я то же самое делаю находясь в Минске? Как определить, где я нахожусь, без интернета?
И это только технические вопросы. При этом самый главный вопрос для менеджера проекта — как часто пользователи Яндекс.Метро не переставляют время в телефоне, вручную или автоматически, уезжая в другую временную зону? Будет ли этот новый функционал неправильно переводить время и у какого процента пользователей?
Кстати, я на 90% уверен, что разработчики данной программы делают не «на отшибись», и очень стараются выпустить качественный продукт. Пожалуй, единственное, с чем можно безоговорочно согласиться в вашей статье — это то, что очень плохо, что в программе нету кнопки «сообщить об ошибке». Как повод для обсуждений — исходные данные графа о времени пересадок. Но вы обсуждения, очевидно, не хотите.
Кстати, вы когда про какие либо фичи пишете (типа попытки определения правильного текущего времени) — то подумайте, на сколько этот кейс популярен и сколько будет стоит их разработка и тестирование. Пока я видел не локальное время на телефоне только у людей, которые забыли его перевести, и при этом изначально ставили ручной перевод часов. Очевидно, что при ответе программы «а метро то уже закрыто» они бы часы перевели. Держать на телефоне московское время, находясь при этом в Минске — очень редкое развлечение.