Саботаж близок по смыслу, а точнее - по форме релизации, то есть скрытое воспрепятствование работе, сохраняя при этом видимости нормальной работы. Но для квалификации чего-либо к саботажу, с моей точки зрения, ключевым фактором является именно срыв работы. Здесь же определяющей целью был не срыв работы как таковой (например, по заказу конкурентов, которым важно просто устранить с рынка игрока), а именно разграбление компании. Поэтому я тоже не могу найти более точного термина. Впрочем, полагаю, этот термин будет уже очень скоро неизбежно придуман. Поскольку одно дело, когда в расход была пущена какая-то частная компания. Другое дело - целое государство.
Стиль изложения, конечно, неплох, хотя слишком прослеживается туннелинг, а именно — продавливание своего мнения насчет этих собеседований.
Тем не менее, хочу сказать несколько слов в защиту Яндекса, уточнив при этом, что не являюсь их сотрудником, и не горю желанием им быть, хотя тоже уже много раз звали на аналогичные должности и зарплаты.
Первое, что хочу сказать, что то, каким будет интервью, решает целиком и полностью работодатель. И если ему важно найти специалиста с конкретными навыками (в данном случае — умением решать сложные алгоритмические задачи), их право устраивать такие испытания, какие они посчитают нужными. Если, конечно, они осознанно это делают, а не потому, что так выдал поисковик по запросу «что спросить на собеседовании».
Многочисленные «одинаковые» собеседования могут действительно показаться избыточными, но если исходить из того, что они действительно хотят подобрать хорошего специалиста, это можно рассматривать как некоторую «диверсификацию» и распределение во времени. Не каждый смог бы выдержать 4х-часовое интервью с такими задачами. В плане разных людей — как раз может быть элементом диверсификации, чтобы получить оценку тебя как кандидата от разных людей в компании.
Ну а насколько им действительно нужны сильные алгоритмисты, им, конечно, виднее. Но предлагаю также взглянуть на ситуацию вообще со стороны как пользователю подобных сервисов. Вот, в Деливери, возможно, гораздо более «правильные» собеседования, но и не стоит удивляться при этом таким случаям, когда ты заказываешь еду за 40 минут до закрытия ресторана, а только через 20 минут уже после закрытия получаешь уведомление «М, извините, мы не успели :( Ресторан уже закрылся.» Все же логистика — не самая простая область.
Собственно говоря, я не столько заголовок уже пытался оспорить, сколько то, что математика — это все же предметная область, или, если эта формулировка смущает, — область знаний, которая пригодилась :) Ну а то, что она может быть нужна некоторым программистам, очевидно :)
Действительно, а причем здесь вообще веб-API? Я вроде про него ни слова не упомянул :) Да и вы сами, собственно говоря, это затронули. Есть весьма изолированная задача, условия и ограничения для которой пришли извне. В данном случае «из веба», но для самой задачи, а равно как и для того, кто будет ее решать, это не имеет никакого значения. От веба мы абстрагировались. Далее… Задача требует преимущественно математического решения, а значит, если бы мы говорили об идеальном мире и идеальной компании, в которой вы работаете, экспертизу в математике предоставил бы отдельный человек — математик, который, в свою очередь, может ничего не знать о программировании. То есть это все же предметная область, экспертиза в которой необходима для решения определенного круга задач в вашем проекте. И если Ваших познаний в ней оказалось достаточно — это прекрасно. Но все же правильно это сформулировать как то, что математика Вам пригодилась. Но это далеко не «математика нужна программистам». И если, допустим, весь ваш проект или существенная его часть постоянно сопряжены с математикой, как в приведенной задаче, то это, очевидно, задача работодателя нанимать разработчиков, обладающих определенными познаниями в математике, если отдельного математика со своей экспертизой содержать нецелесообразно. Но так же очевидно, что далеко не во всех проектах реального мира требуются эти знания. Равно, как и наоборот: есть множество проектов, где полезны знания в совершенно других областях. Вот только найти программиста, готового предоставить экспертизу, например, по химии, или по любой другой предметной области, не всегда просто, надо полагать. А в данных примерах нет причин считать, что химия отличается от математики как абстрактная предметная область.
Я скажу честно: увидев раздел «Формулировка задачи», даже не стал читать. Согласен и насчет того, что заголовок слишком провокационный (я как раз только что закрыл статью «как НЕ на надо изучать программирование»), и насчет того, что заголовок должен быть громким. Но раз уж встал вопрос о заголовке, наиболее емко отражающем суть, мое мнение таково, что в данном конкретном случае математика — это чистой воды предметная область, а не общее требование к разработчику. Или, если уж говорить о конкретном заголовке, то он скорее все был бы таким: «Математика может пригодиться программисту».
Уже многое сказано о том, что математика не нужна для изучения программирования, с чем я абсолютно согласен. Я лишь приведу один простой пример из реальной жизни: есть такой очень известный язык программирования Perl. Так вот, его создатель, Ларри Уолл, является лингвистом по образованию, а в детские годы так и вообще хотел в будущем быть просто служителем церкви. Но, тем не менее, интерес, а главное способности к программированию у него проявились уже непосредственно в университете при отсутствии особых склонностей к математике.
Неожиданно?
Стоит ли говорить о том, какое влияние этот язык оказал на развитие области в целом? И ему (автору) не мешало при этом отсутствие особых знаний в математике. Более того, для него даже переменные и функции — это «существительные» и «глаголы», «подлежащие» и «сказуемые», и так далее.
Очевидно, любой профессии надо учиться, и ни один человек не становится гуру какого-либо дела сразу после ознакомительных экспресс-курсов, или прочтения пары книжек :) Поэтому даже «лапша» на начальных этапах обучения — вполне нормально. И дальнейшее развитие в области разработки будет включать в том числе и умение писать код грамотно.
Спасибо, ваши комментарии вполне справедливы :) Я лишь напомню, что только начинаю изучать Го и некоторые моменты, специфичные для Го, еще очевидно не знаю на все 100%. Но все же отвечу по порядку предъявленных обвинений :)
1) Тут вы безусловно правы. Но это же пока еще только «болванка» для дальнейшей логики. Соотв-но все детали еще конечно не учтены. Если говорить конкретно об этих моделях (Expense и Diary), валидация и прочие вещи еще впереди.
2) Про работу со списком я вроде бы же написал, что этот список будет сокрыт внутри Diary, и вся работа с ним будет производиться исключительно самим Diary, включая и проверку, что туда вообще может попасть. Аналогично про «стандартную беду» Го тоже не соглашусь. Этот пакет предоставляет общее решение для списков, а уж конкретное применение, включая ту же валидацию и прочие вещи, решает уже непосредственно использующая сторона.
3) По этому поводу я уже частично успел оправдаться, говоря о не 100% знании всех аспектов Го :) В данном случае я руководствовался соображениями из других языков, где применяются конструкции вида throw exception; А сам exception, если он предусмотрен заранее, отлавливается выше. Соотв-но по своему незнанию воспринял panic как механизм, аналогичный throw :)
Про «обмазаться кодом» и другие аргументы наподобие «другие уже закончат три таких проекта», то продумывать ли сразу архитектуру приложения или просто наговнячить по-быстрому ради MVP, решает, конечно, каждый сам. И тут уже совершенно не имеет значения, о каком ЯП речь: Го или не Го. Я лишь уточню, что в этом мини-проекте ставлю своей целью в том числе и лишний раз отработать применение архитектурных принципов даже на таком маленьком приложении. Кто знает, может захочу из него потом потом сделать полноценное приложение для ведения финансового учета :) Ну и лишний раз проверить, насколько закладываемая изначально архитектура позволит дальше расширять проект без особой боли.
Плюсую, статья хорошая. Докопаться, конечно, и до столба можно, как известно, но суть раскрыта нормально. Думал кстати тоже аналогичную статью запостить с конкретным примером рефакторинга.
Основная проблема, с которой столкнулся автор: неудачные материалы для обучения, и как следствие «кто в лес, кто по дрова».
Прям как на этой гифке
У меня нет опыта преподавания кому-то программирования в целом, но я бы предположил, что стоит пойти по такому пути. Понятно, что одним комментарием вряд ли можно всему научить, но тем не менее, попробую дать направляющие.
Начать с алгоритмов на базовом уровне, как последовательность инструкций кому-то («зайди в магазин», «возьми с полки пачку конфет», «оплати на кассе»), заодно освоив такие вещи, как ветвления («если закончилась еда, то сходи в магазин») и циклы («отожмись от пола 10 раз», «занимайся каждый день, пока не сдашь экзамен» и так далее).
Взять простейший язык программирования, как уже советовали ранее. Пускай даже BASIC или Паскаль. И начать формулировать на нем простейшие алгоритмы. Например: «1) считать число с клавиатуры; 2) если это число меньше 18, то написать на экране «Несовершеннолетний», иначе написать «Совершеннолетний»». И так далее. Постепенно усложняя алгоритмы, добавляя больше ветвлений и циклов.
Прийти к пониманию необходимости вынесения повторяющихся действий в отдельные места в коде (процедуры / функции). В примере выше «сходи в магазин» может быть отдельной процедурой. Если закончилась еда, то <сходить в магазин>.
Процедура <сходить в магазин>:
Дойти до магазина.
Купить нужные продукты.
Вернуться домой.
Попутно поняв, что эти процедуры можно сделать гибкими за счет параметров. Например процедуру «сходить в магазин» можно снабдить параметрами, говорящими, что именно надо купить в магазине. Сама процедура по сути остается та же, но она каждый раз позволит покупать разные продукты. А в качестве практики, реализовывать подобные на языке программирования, где в качестве инструкций уже будут инструкции именно для компьютера: прочитать ввод пользователя, проанализировать его, прочитать или записать что-то в/из файла, и так далее.
Ознакомиться с простейшими типами данных и понять разницу между ними: числа, строки, boolean (да/нет) и так далее. Ознакомиться с составными типами данных, например массивы: массив чисел, массив строк, и так далее. Например, может быть массив чисел, содержащий все оценки ребенка по математике за последний месяц: [5,4,4,5,3,5,5,5,4]. И в качестве практики, можно попробовать высчитать при помощи ЯП средний балл за этот месяц.
Постепенно можно прийти к понимаю ООП. Например, есть общий тип данных (класс) «Школьник», и есть конкретные «воплощения» этого класса (объекты): «Вася», «Петя», «Вова». Класс «Школьник» может содержать метод (процедуру) «Нарисовать рисунок», но каждый конкретный школьник может его реализовывать по-своему. Условно, учитель дает всем «Школьникам» задание «Нарисовать рисунок», вызвав соответствующий метод у каждого конкретного ученика («Вася.Нарисовать_рисунок», «Петя.Нарисовать_рисунок» и так далее), но каждый ученик сделает рисунок по-своему. Учитель взаимодействует с учениками, как со «Школьниками» (объектами класса «Школьник») не зная об их специфических особенностях. Соотв-но, все эти действия можно перевести и в компьютерную плоскость.
Ну и практика, практика, практика. Постоянно усложняя себе задачи, а также пробуя себя в различных «средах» (графика/игры, веб, десктопные или мобильные приложения, и так далее) и постепенно их осваивая, изучая имеющиеся в современном мире инструментарии для реализации тех или иных задач, и «набивая шишки».
Важно также понимать, что конкретный ЯП не важен. Важно понять суть происходящего, а конкретный ЯП уже будет просто синтаксисом, позволяющим сформулировать те или иные вещи компьютеру.
Много ли пользователей у бота? Не сталкиваетесь ли с лимитом сообщений при рассылке уведомлений? Сам на днях написал первого бота, хочу тоже рассылать уведомления, но прочитал, что есть лимиты.
Мб этот подход и не очень плох, но я бы не разбирал сообщения в основном цикле, а передал эту работу следующей абстракции, будь то "контроллер" или менеджер команд. И вообще, лучше как мне кажется через webhook работать.
Это как раз то, чего давно не хватает, и что давно просят добавить, в моей библиотечке localized-carbon. Сейчас она только умеет локализовывать разницу во времени, типо «3 часа назад», «5 лет назад» и т.д.
Стоит еще упомянуть весьма полезный пакет Laravel-4-Generators от Jeffrey Way (ведущего Laracasts). Этот пакет является на данный момент самым популярным, если верить сайту Packalyst.com. Позволяет немного ускорить процесс разработки за счет генерации различных «болванок» под модели, вьюхи, и т.д.
Саботаж близок по смыслу, а точнее - по форме релизации, то есть скрытое воспрепятствование работе, сохраняя при этом видимости нормальной работы. Но для квалификации чего-либо к саботажу, с моей точки зрения, ключевым фактором является именно срыв работы. Здесь же определяющей целью был не срыв работы как таковой (например, по заказу конкурентов, которым важно просто устранить с рынка игрока), а именно разграбление компании. Поэтому я тоже не могу найти более точного термина. Впрочем, полагаю, этот термин будет уже очень скоро неизбежно придуман. Поскольку одно дело, когда в расход была пущена какая-то частная компания. Другое дело - целое государство.
Тем не менее, хочу сказать несколько слов в защиту Яндекса, уточнив при этом, что не являюсь их сотрудником, и не горю желанием им быть, хотя тоже уже много раз звали на аналогичные должности и зарплаты.
Первое, что хочу сказать, что то, каким будет интервью, решает целиком и полностью работодатель. И если ему важно найти специалиста с конкретными навыками (в данном случае — умением решать сложные алгоритмические задачи), их право устраивать такие испытания, какие они посчитают нужными. Если, конечно, они осознанно это делают, а не потому, что так выдал поисковик по запросу «что спросить на собеседовании».
Многочисленные «одинаковые» собеседования могут действительно показаться избыточными, но если исходить из того, что они действительно хотят подобрать хорошего специалиста, это можно рассматривать как некоторую «диверсификацию» и распределение во времени. Не каждый смог бы выдержать 4х-часовое интервью с такими задачами. В плане разных людей — как раз может быть элементом диверсификации, чтобы получить оценку тебя как кандидата от разных людей в компании.
Ну а насколько им действительно нужны сильные алгоритмисты, им, конечно, виднее. Но предлагаю также взглянуть на ситуацию вообще со стороны как пользователю подобных сервисов. Вот, в Деливери, возможно, гораздо более «правильные» собеседования, но и не стоит удивляться при этом таким случаям, когда ты заказываешь еду за 40 минут до закрытия ресторана, а только через 20 минут уже после закрытия получаешь уведомление «М, извините, мы не успели :( Ресторан уже закрылся.» Все же логистика — не самая простая область.
Стоит ли говорить о том, какое влияние этот язык оказал на развитие области в целом? И ему (автору) не мешало при этом отсутствие особых знаний в математике. Более того, для него даже переменные и функции — это «существительные» и «глаголы», «подлежащие» и «сказуемые», и так далее.
1) Тут вы безусловно правы. Но это же пока еще только «болванка» для дальнейшей логики. Соотв-но все детали еще конечно не учтены. Если говорить конкретно об этих моделях (Expense и Diary), валидация и прочие вещи еще впереди.
2) Про работу со списком я вроде бы же написал, что этот список будет сокрыт внутри Diary, и вся работа с ним будет производиться исключительно самим Diary, включая и проверку, что туда вообще может попасть. Аналогично про «стандартную беду» Го тоже не соглашусь. Этот пакет предоставляет общее решение для списков, а уж конкретное применение, включая ту же валидацию и прочие вещи, решает уже непосредственно использующая сторона.
3) По этому поводу я уже частично успел оправдаться, говоря о не 100% знании всех аспектов Го :) В данном случае я руководствовался соображениями из других языков, где применяются конструкции вида throw exception; А сам exception, если он предусмотрен заранее, отлавливается выше. Соотв-но по своему незнанию воспринял panic как механизм, аналогичный throw :)
Про «обмазаться кодом» и другие аргументы наподобие «другие уже закончат три таких проекта», то продумывать ли сразу архитектуру приложения или просто наговнячить по-быстрому ради MVP, решает, конечно, каждый сам. И тут уже совершенно не имеет значения, о каком ЯП речь: Го или не Го. Я лишь уточню, что в этом мини-проекте ставлю своей целью в том числе и лишний раз отработать применение архитектурных принципов даже на таком маленьком приложении. Кто знает, может захочу из него потом потом сделать полноценное приложение для ведения финансового учета :) Ну и лишний раз проверить, насколько закладываемая изначально архитектура позволит дальше расширять проект без особой боли.
Плюсую, статья хорошая. Докопаться, конечно, и до столба можно, как известно, но суть раскрыта нормально. Думал кстати тоже аналогичную статью запостить с конкретным примером рефакторинга.
У меня нет опыта преподавания кому-то программирования в целом, но я бы предположил, что стоит пойти по такому пути. Понятно, что одним комментарием вряд ли можно всему научить, но тем не менее, попробую дать направляющие.
Если закончилась еда, то <сходить в магазин>.
Процедура <сходить в магазин>:
Дойти до магазина.
Купить нужные продукты.
Вернуться домой.
Попутно поняв, что эти процедуры можно сделать гибкими за счет параметров. Например процедуру «сходить в магазин» можно снабдить параметрами, говорящими, что именно надо купить в магазине. Сама процедура по сути остается та же, но она каждый раз позволит покупать разные продукты. А в качестве практики, реализовывать подобные на языке программирования, где в качестве инструкций уже будут инструкции именно для компьютера: прочитать ввод пользователя, проанализировать его, прочитать или записать что-то в/из файла, и так далее.
Важно также понимать, что конкретный ЯП не важен. Важно понять суть происходящего, а конкретный ЯП уже будет просто синтаксисом, позволяющим сформулировать те или иные вещи компьютеру.
Много ли пользователей у бота? Не сталкиваетесь ли с лимитом сообщений при рассылке уведомлений? Сам на днях написал первого бота, хочу тоже рассылать уведомления, но прочитал, что есть лимиты.
Мб этот подход и не очень плох, но я бы не разбирал сообщения в основном цикле, а передал эту работу следующей абстракции, будь то "контроллер" или менеджер команд. И вообще, лучше как мне кажется через webhook работать.
Switchercoin: Switcherport was stopped
Middlecoin: