А если это code review? Или если нет «корпоративных требований оформления кода», то в целом и code review бессмысленно проводить?
Если на code-review проверяется только оформление кода и неизбыточность комментариев, то, скорее всего, бессмысленно. Обычно же на code-review ищут ошибки (реальные и потенциальные), несоответствие требованиям, критические недочёты, непонятные места.
Не совсем понятно, в чем проблема? Вы хотите его убедить, не писать комментарии? Или он пытается вас убедить их писать? На мой взгляд никакой проблемы нет. Если нет "корпоративного требования оформления кода", то пусть разработчик сам решает, писать ли ему комментарии в очевидных случаях.
А скажите, пожалуйста, каков мотив для выбора именно трехслойки с такими количествами нейронов?
В статье этот выбор не совсем «обоснованный». Надо было протестировать реализацию (поискать ошибки в коде), попробовал разные варианты, выбрал тот, где шаг считается не очень долго, а значение функции потерь уменьшается сильно. Для реальной работы так делать, конечно, не стоит. Надо полноценно проверять разные архитектуры кросс-валидацией, и только потом осознанно выбирать наиболее подходящую.
Почему не однослойка? Ведь любую функцию (а в данном случае аппроксимировалась функция), можно аппроксимировать однослойкой?
Это очень интересный вопрос. С одной стороны, есть универсальная теорема аппроксимации, которая утверждает, что при достаточном количестве нейронов однослойный перцептрон может аппроксимировать любую непрерывную функцию с любой точностью при удачном подборе параметров. С другой стороны, эта теорема не отвечает на 2 важных вопроса:
1. Достаточно — это сколько? И может ли оказаться, что для многослойной сети достаточное количество будет гораздо меньше, чем для однослойной?
2. Как удачно подобрать параметры, когда количество нейронов достаточное?
Пока ответов на эти вопросы нет, и зачастую ML похоже на алхимию: "попробуйте нейронную сеть с 1, 2, 3, 4 слоями, с количеством нейронов 1X-4X, где X размерность входного вектора, кросс-валидацией выберите подходящую архитектуру". Вместо ответов есть опыт-наблюдения:
Зачастую многослойной сетью получается добиться лучшего результата меньшим количеством параметров. Где-то слышал, что приводился пример функции, которая аппроксимировалась конечной сетью с двумя слоями, но однослойная требовала бесконечного числа параметров. Возможно, я неправильно понял.
Обучать многослойную сеть проще. Можно привести аналогию с ассемблером. Теоретически, любую программу можно написать на ассемблере. Практически, это очень сложно. Но как только написана программа на С, перевести в ассемблер её можно запросто. Где-то слышал, что учёные проделывали схожее для нейронных сетей — подбирали параметры для многослойной, и на базе этого вычисляли параметры для однослойной сети. Но подобрать параметры сразу для однослойной не получалось.
Мне кажется, что на пост советском пространстве у людей есть врождённая потребность учить друг друга. Автомобилисты на дорогах учат других автомобилистов. Старослужащие учат «новослужащих». Раньше иной раз в поезде нельзя было проехаться без того, чтобы тебя не поучили жизни (каждый своей собственной). А так как опыта, педагогического образования, или желания прочитать статью «как учить за жизнь правильно» нет, то и учат зачастую резко тормозя перед новичками, тумаками, матом, ремнём, разносом на code review.
Хотя, возможно, я придираюсь, и в других странах так же.
Не лучше ли "- вот в требованиях есть (подразумевалось) такое поведение, а в этом коде оно не реализовано, надо реализовать. — требования нечёткие, но теперь я понял, пошёл реализовывать, а ты уточни требования, чтобы QA не поняли так же как я сначала и не заводили несуществующих багов"?
Да, так отлично. И мало кто назовёт такой диалог «токсичным»:
1. Нет никаких оскорблений, грубых слов или повышенного тона.
2. Нет претензий сотрудников друг к другу. Есть неработающий код, невыполненные требования, неуточнённые требования, несуществующие баги. Это проблемы, которые нужно решать и устранять. Обычная рабочая ситуация.
Старым себя не считаю, но застал немного того времени, когда нормой было курить за рабочим местом, обматерить за ошибку, посраться чуть ли не до драки «за полиморфизм» на свадьбе программиста, раскидываться направо и налево термином «говнокод», считать ниже себя всех тех, кто не знает (не использует) UML. Эдакий брутальный мирок программистов.
Сейчас с печеньками, смузи, непрокуренным офисом с дизайнерским ремонтом, и уважительным отношением друг к другу мне нравится больше.
Честно говоря, не работал с Matlab. Просто довольно часто на форумах встречал скриншоты из этой системы. Прочитать, как визуализировать, можно, например, здесь: blogs.mathworks.com/loren/2015/08/04/artificial-neural-networks-for-beginners По ссылке есть визуализация для классификации. По-моему, выглядит очень хорошо и понятно:
Много красивой математики. Безусловный плюс в карму, но вопрос, а не кажется ли вам, что отсутствие реализаций этого метода не случайно?
Спасибо!
Думаю, что реализации этого метода «из коробки» в TensorFlow нет, так как TensorFlow обычно использую для других задач: работа с изображением, звуком, с натуральным языком. В этих случаях количество параметров исчисляется сотнями тысяч. Методам второго порядка там делать нечего.
В Matlab реализация есть, и даже предлагается как алгоритм первого выбора: "trainlm is often the fastest backpropagation algorithm in the toolbox, and is highly recommended as a first-choice supervised algorithm, although it does require more memory than other algorithms." (Levenberg-Marquardt backpropagation — MATLAB trainlm). Matlab используют инженеры и учёные, у них маленькие нейронные сети для аппроксимации сложных функций, похоже, встречаются чаще.
В свете этого либо я умею получать вторые производные, но не понимаю чего-то важного, либо вы, как и когда-то, вложили кучу интеллектуальных усилий в дело вместо того чтобы взять задачу грубой рассчётной силой в три раза быстрее. Ради красоты алгоритма или потому что ещё по чему.
Мне просто было интересно. А команда моего друга-нефтяника перепробовала кучу подходов, но сработал только этот. С остальными методами они просто не смогли дождаться приемлемой точности, несмотря на очень хорошее «железо». У них довольно жесткое условие было: либо добиваются требуемой точности, либо решение будет никому не нужно.
как мне кажется, с шумом все достоинства вторых производных сойдут на нет
График для ситуации без шума. Самому стало интересно, как шум и его уровень повлияют на разные алгоритмы. На выходных запущу оптимизацию для разных случаев, и выложу результаты.
Ждал от статьи каких-нибудь цифр, выводов, статистики, или хотя бы личного примера. Слово «больше» в теме статьи предполагает намёки на ответы на вопросы: «больше чего?», «больше насколько?»…
Да оно и не работает, если подходить с рациональной точки зрения. Те кто реально умеет и хочет работать, тот работает без тимбилдингов и корпоративов, на результат, и нормально взаимодействует с сотрудниками
Вопрос не только в работе на результат. Это PR.
Есть PR внешний — когда после хорошей корпоративной вечеринки в Инстаграме сотрудников появляются фотографии оттуда. В итоге компания на слуху. Поток резюме выше. Есть возможность выбирать. Действует не на всех, но цели зацепить всех и нет.
Есть PR внутренний — чтобы сотрудники чувствовали себя причастными к чему-то большему, чем написание кода для очередной бухгалтерии. Работает тоже не на всех. Но отток сотрудников становится меньше. Мне по большей части тусовки не очень интересны. Но даже я иногда думаю: «Ёлки, а ведь реально очень круто получилось (было)!».
Как итог: немного увеличили приток кандидатов, немного уменьшили отток сотрудников, теперь есть из кого выбирать и можно оставлять тех, кто «кто реально умеет и хочет работать»…
Именно так, бизнес: это работает, это выгодно, поэтому так и делают. Приносило бы одни убытки, не делали бы. Понятно, что на взрослых семейных людей это действует так себе, но молодым специалистам хочется тусовки, движения, выездов, корпоративов и красивых сотрудниц там. В итоге в одном здании может сидеть несколько похожих компаний, но поток резюме будет выше в ту, в которой вечеринки круче.
Если рыночная стоимость ваших побочных продуктов самоудовлетворения соответствует вашим финансовым притязаниям. Я работаю именно так: делаю то, что мне интересно и получаю за это неплохие деньги. Как только меня попытаются впихнуть в какие-то некомфортные для меня рамки — я помашу ручкой.
Вот это вот и есть зрелая позиция: придти в ситуацию win-win, когда выигрывает и бизнес и вы. Придти в это состояние можно многими путями. Проще всего устроиться в правильную для вас компанию, а не воевать со всеми работодателями мира. У автора же статьи вся жизнь борьба: 1) собеседующие vs собеседуемые; 2) full stack vs узкая специализация; 3) dynamic vs static; 4) корпорация vs личность программиста. Это незрелая позиция.
Анализ рынка сложная штука. То что пишут в вакансиях обязанность-компенсация обычно не отражает ни реальные скиллы ни реальный размер оплаты.
Как я понимаю, в данном случае точный анализ рынка не самоцель. Задача, чтобы сотрудники массово не уходили из команды (так как сразу же за углом предлагают значительно больше), чтобы сотрудники не были демотивированы размером прибавки, и чтобы ФОП не выходил за установленные рамки. Если все эти цели достигнуты, то точность анализа рынка «нормальная», значительно её улучшать можно только из-за любви к искусству.
Насколько мне известно, в Новосибирске есть широкополосный интернет, что позволяет зарабатывать по всему миру?
У нас же свободная страна. Кто хочет, тот и зарабатывает через интернет. Но пока есть довольно много разработчиков, которые готовы ходить в офис, компаниям не имеет никакого смысла платить разработчику в Новосибирске зарплату уровня США.
Моё мнение: скорее нет, если исходить из практики.
Моё мнение несколько другое. Если вы не знаете математики, то в работе программистом она вам, скорее всего, никогда не понадобится. Вам просто не будут давать задачи, с ней связанные, вы не будете устраиваться на те должности и в те компании, где она требуется и т.д… Но с другой стороны, даже минимальные знания математики в программировании очень сильно расширяют горизонт деятельности и увеличивают количество возможностей.
А в чем разница между эникейщиком и fullstack'ом, описанным в статье?
Думаю, что в «официальных» словарях такого слова нет, народные интернет-словари дают такие определения:
эникейщик — Название должности «специалиста по всему» в области компьютеров, оргтехники, телефонии, не требующей углублённых знаний. Он решает мелкие простые повседневные проблемы рядовых пользователей, чтобы не отнимать ценное время у админов
эникейщик — помощник системного администратора или сотрудник техподдержки (в основном занимается тем, что разбирается с пустяковыми проблемами пользователей; происходит от названия несуществующей клавиши any key, которую система просит нажать...
эникейщик — шуточное название штатной должности работника, обязанностью которого является техническая поддержка пользователей компьютера внутри компании
Т.е. совершенно ничего общего с тем, что написано в статье. У вас, конечно, может быть своё собственное определение, но не вижу смысла это ваше личное определение обсуждать.
А ведь еще несколько лет назад fullstack'и назывались эникейщиками. Казалось бы — суть одна, зато как теперь гордо звучит.
Несколько лет назад — это сколько? Вроде бы я в профессии уже больше 15 лет, но никогда ни разу не слышал, чтобы fullstack'а называли эникейщиком. И суть совершенно разная. Скорее даже наоборот, лет 10 назад было вполне нормальным, что разработчик пишет и бэк (включая БД) и фронт (хотя, может это так мне повезло). Но сейчас всё усложнилось сильно, особенно фронт, и теперь очень сложно быть сильным во всём.
«Как это, не нужна? Я что, зря пахал по 70-100 часов в неделю, не видел семью, друзей, частично облысел и, в итоге, стал похож на носферату? Алло! Вы меня решили кинуть?»
Наёмному работнику (разработчику в частности) желательно стремиться за свою работу получать честную компенсацию. В моменте. Если человек работал по 100 часов в неделю и получал тройную зарплату, то потом не будет никаких причин обижаться и расстраиваться.
Согласиться с коллегой, что действительно не нужна?
Если на code-review проверяется только оформление кода и неизбыточность комментариев, то, скорее всего, бессмысленно. Обычно же на code-review ищут ошибки (реальные и потенциальные), несоответствие требованиям, критические недочёты, непонятные места.
Не совсем понятно, в чем проблема? Вы хотите его убедить, не писать комментарии? Или он пытается вас убедить их писать? На мой взгляд никакой проблемы нет. Если нет "корпоративного требования оформления кода", то пусть разработчик сам решает, писать ли ему комментарии в очевидных случаях.
В статье этот выбор не совсем «обоснованный». Надо было протестировать реализацию (поискать ошибки в коде), попробовал разные варианты, выбрал тот, где шаг считается не очень долго, а значение функции потерь уменьшается сильно. Для реальной работы так делать, конечно, не стоит. Надо полноценно проверять разные архитектуры кросс-валидацией, и только потом осознанно выбирать наиболее подходящую.
Это очень интересный вопрос. С одной стороны, есть универсальная теорема аппроксимации, которая утверждает, что при достаточном количестве нейронов однослойный перцептрон может аппроксимировать любую непрерывную функцию с любой точностью при удачном подборе параметров. С другой стороны, эта теорема не отвечает на 2 важных вопроса:
1. Достаточно — это сколько? И может ли оказаться, что для многослойной сети достаточное количество будет гораздо меньше, чем для однослойной?
2. Как удачно подобрать параметры, когда количество нейронов достаточное?
Пока ответов на эти вопросы нет, и зачастую ML похоже на алхимию: "попробуйте нейронную сеть с 1, 2, 3, 4 слоями, с количеством нейронов 1X-4X, где X размерность входного вектора, кросс-валидацией выберите подходящую архитектуру". Вместо ответов есть опыт-наблюдения:
Хотя, возможно, я придираюсь, и в других странах так же.
Да, так отлично. И мало кто назовёт такой диалог «токсичным»:
1. Нет никаких оскорблений, грубых слов или повышенного тона.
2. Нет претензий сотрудников друг к другу. Есть неработающий код, невыполненные требования, неуточнённые требования, несуществующие баги. Это проблемы, которые нужно решать и устранять. Обычная рабочая ситуация.
Сейчас с печеньками, смузи, непрокуренным офисом с дизайнерским ремонтом, и уважительным отношением друг к другу мне нравится больше.
blogs.mathworks.com/loren/2015/08/04/artificial-neural-networks-for-beginners По ссылке есть визуализация для классификации. По-моему, выглядит очень хорошо и понятно:
Спасибо!
Думаю, что реализации этого метода «из коробки» в TensorFlow нет, так как TensorFlow обычно использую для других задач: работа с изображением, звуком, с натуральным языком. В этих случаях количество параметров исчисляется сотнями тысяч. Методам второго порядка там делать нечего.
В Matlab реализация есть, и даже предлагается как алгоритм первого выбора: "trainlm is often the fastest backpropagation algorithm in the toolbox, and is highly recommended as a first-choice supervised algorithm, although it does require more memory than other algorithms." (Levenberg-Marquardt backpropagation — MATLAB trainlm). Matlab используют инженеры и учёные, у них маленькие нейронные сети для аппроксимации сложных функций, похоже, встречаются чаще.
Мне просто было интересно. А команда моего друга-нефтяника перепробовала кучу подходов, но сработал только этот. С остальными методами они просто не смогли дождаться приемлемой точности, несмотря на очень хорошее «железо». У них довольно жесткое условие было: либо добиваются требуемой точности, либо решение будет никому не нужно.
График для ситуации без шума. Самому стало интересно, как шум и его уровень повлияют на разные алгоритмы. На выходных запущу оптимизацию для разных случаев, и выложу результаты.
Вопрос не только в работе на результат. Это PR.
Есть PR внешний — когда после хорошей корпоративной вечеринки в Инстаграме сотрудников появляются фотографии оттуда. В итоге компания на слуху. Поток резюме выше. Есть возможность выбирать. Действует не на всех, но цели зацепить всех и нет.
Есть PR внутренний — чтобы сотрудники чувствовали себя причастными к чему-то большему, чем написание кода для очередной бухгалтерии. Работает тоже не на всех. Но отток сотрудников становится меньше. Мне по большей части тусовки не очень интересны. Но даже я иногда думаю: «Ёлки, а ведь реально очень круто получилось (было)!».
Как итог: немного увеличили приток кандидатов, немного уменьшили отток сотрудников, теперь есть из кого выбирать и можно оставлять тех, кто «кто реально умеет и хочет работать»…
Именно так, бизнес: это работает, это выгодно, поэтому так и делают. Приносило бы одни убытки, не делали бы. Понятно, что на взрослых семейных людей это действует так себе, но молодым специалистам хочется тусовки, движения, выездов, корпоративов и красивых сотрудниц там. В итоге в одном здании может сидеть несколько похожих компаний, но поток резюме будет выше в ту, в которой вечеринки круче.
Вот это вот и есть зрелая позиция: придти в ситуацию win-win, когда выигрывает и бизнес и вы. Придти в это состояние можно многими путями. Проще всего устроиться в правильную для вас компанию, а не воевать со всеми работодателями мира. У автора же статьи вся жизнь борьба: 1) собеседующие vs собеседуемые; 2) full stack vs узкая специализация; 3) dynamic vs static; 4) корпорация vs личность программиста. Это незрелая позиция.
Как я понимаю, в данном случае точный анализ рынка не самоцель. Задача, чтобы сотрудники массово не уходили из команды (так как сразу же за углом предлагают значительно больше), чтобы сотрудники не были демотивированы размером прибавки, и чтобы ФОП не выходил за установленные рамки. Если все эти цели достигнуты, то точность анализа рынка «нормальная», значительно её улучшать можно только из-за любви к искусству.
У нас же свободная страна. Кто хочет, тот и зарабатывает через интернет. Но пока есть довольно много разработчиков, которые готовы ходить в офис, компаниям не имеет никакого смысла платить разработчику в Новосибирске зарплату уровня США.
Моё мнение несколько другое. Если вы не знаете математики, то в работе программистом она вам, скорее всего, никогда не понадобится. Вам просто не будут давать задачи, с ней связанные, вы не будете устраиваться на те должности и в те компании, где она требуется и т.д… Но с другой стороны, даже минимальные знания математики в программировании очень сильно расширяют горизонт деятельности и увеличивают количество возможностей.
Думаю, что в «официальных» словарях такого слова нет, народные интернет-словари дают такие определения:
Т.е. совершенно ничего общего с тем, что написано в статье. У вас, конечно, может быть своё собственное определение, но не вижу смысла это ваше личное определение обсуждать.
Несколько лет назад — это сколько? Вроде бы я в профессии уже больше 15 лет, но никогда ни разу не слышал, чтобы fullstack'а называли эникейщиком. И суть совершенно разная. Скорее даже наоборот, лет 10 назад было вполне нормальным, что разработчик пишет и бэк (включая БД) и фронт (хотя, может это так мне повезло). Но сейчас всё усложнилось сильно, особенно фронт, и теперь очень сложно быть сильным во всём.
Наёмному работнику (разработчику в частности) желательно стремиться за свою работу получать честную компенсацию. В моменте. Если человек работал по 100 часов в неделю и получал тройную зарплату, то потом не будет никаких причин обижаться и расстраиваться.