Превосходно. У вас есть GPU (или любой другой специализированный вычислитель) и необходимо решить задачу через матричные вычисления, но у вас же есть "свои" методы, которыми вы успешно решаете на CPU.
Это провал Карл! Ваше решение не оптимально!
Дифуры и физика — это всего лишь инструменты, так же как CPU и GPU. И нужно уметь пользоваться ими, а не показать, какой вы молодец. И замечу — способность видеть множество решений — это только плюс вам. Но решение обязано подпадать под ТЗ. Иначе вы подставляете человека.
Просто подумайте, у вас попросили отмерить 1 метр оптоволокна, но вы решили, что отмерить 2 фута будет проще. Как потом быть заказчику? Смысл именно в инструментах и стандартах.
Это относится к функциональным языкам — у них есть своя специфика, которая и позволяет обходить глобальные состояния… за счет глобальных монад. Да что уж, предлагаю пойти дальше — класс, функция — это тоже глобальный объект, в своем роде. Только вот их глобальность скрыта ЯП и не доступна, обычно, программисту. Хотя умельцы патчат классы в рантайме прямо в виртуалке при загрузке этих классов — AspectJ как пример.
И да, как решение для ликвидации глобального состояния — ФОП отличное решение.
А в остальных случаях как? Или идеализм и перфекционизм вездесущи и все строем должны идти учить хаскель?
Ты решение из другой сферы взял, и при этом не достиг цели.
Вот если бы ты в контексте дифуров придумал свое решение, пусть даже менее элегантное — это было бы круто.
Ваш вариант — это в соревновании бега в мешках пробить в нем дно и бежать.
Решение не подпадает под заданную цель. Считайте это как ТЗ.
В целом же, в абстрактном случае, получи вы такую же задачу с просьбой решить — ваше решение было бы как раз самым правильным, потому что дифуры — это микроскопом гвозди забивать, когда есть более простое и доступное решение.
Где же в вашем первоначальном комментарии "правильно, как учили"?
В свое время так же занимался правкой багов во freecol. Одновременно писал к нему новый ИИ, который бы никогда не закончил.
Пока писал ИИ, с его помощью нашел баг в сервере.
В целом помощь в рефакторинге, исправил пару багов в клиенте и один в сервере.
Вроде бы участвовал только пару месяцев, зато очень хорошо помогло войти в курс дела разработки на Java. По времени ушло где-то 80 часов рабочего времени летом, а опыт использую до сих пор.
Если хотите чему-то научиться — ставьте себе невыполнимые задачи и шаг за шагом ее реализуйте. А опенсорс для этого самое лучшее начало. Гнаться за деньгами вот так вот сразу — бесперспективно. В любой области.
Допустим, что убираем checked. Вообще никаких исключений не видно, которые мог бы выбросить фреймворк, например для работы с http.
Что именно ловить? Checked исключения — это вариант возвращаемого значения с приятным бонусом в виде неявного завершения блока кода, вместо проверок возвращаемого методом кода (результата) — ловишь исключение. Это не только код упрощает, но и избавляет от нужды читать список констант (почему все упало) и пользоваться какими-то левыми инструментами, что бы получить детали.
А насчет заворачивания исключений многократно могу лишь сказать так: руки кривые и излишнее проектирование. Не каждый уровень бизнес-логики вообще требует какой-либо работы с исключениями.
Исключения не везде нужны. В лучшем случае в 1% функционала его требует обязательно, все остальное — проектирование ради проектирования.
Вот чего не хватает в Java, так это возможности сказать, что любые исключения в этом методе считать unchecked — как раз избавится от ручного управления списком throws. Современные IDE и компиляторы вполне умны, что бы понять какое исключение может быть в вызываемом методе и передать его выше. Для этого вроде как даже Java Reflections достаточно, информация присутствует.
Но для этого же существует суффикс при определении метода: throws И не нужно тогда ничего обрабатывать, при этом верхние уровни абстракции получат всю информацию о том, что использует ваша библиотека.
Насчет использования исключений в стиле goto не совсем согласен (ошибка 4), есть % тех случаев, которые просто требуют именно выброса исключений.
Как пример: Вы трассируете некую структуру данных (предположительно неограниченную — граф, дерево или список списков) и создаете собственную структуру данных с ограничением: не более N узлов.
Делать постоянные проверки на останов — снижение быстродействия более чем в 10 раз (такой код уже не будет оптимизироваться JIT даже если вы гуру в Java), не говоря о значительной потере читаемости такого кода, в котором везде и всюду if-else натыканы. С исключениями работает почти мгновенно. Разумеется исключение должно при этом иметь адекватное название, например TraceNodeLimitExceededException.
Так что ошибка 4 является ошибкой далеко не всегда.
Правильнее было бы назвать — рекомендация: "Не используйте исключения для управления ходом исполнения приложения, если нет значительной потери в быстродействии или читаемости кода."
Нет смысла лишать себя возможности сразу прекратить выполнение целого блока кода, если это позволит сделать код читаемым и не пестрить везде и всюду проверками.
Бывают, конечно. Но зачем туда идти если есть возможность пойти в нормальную организацию? И нервы сохраняться, опыт сразу пойдет и по деньгам будет веселее. Гугл + голова зачастую помогает не пойти работать в болото.
Асоциальность и не туда затянуть может. Вы недооцениваете степень замкнутости людей и неспособность (нежелание?) понимать окружающих.
Не знаю никаких проблем с самоуважением. А рвать в гугл только ради престижа? Деньги? Иммигрировать? Личная жизнь? Вы о чем?
Ну пока учился можно хоть эникейщиком, хоть дворником в ИТ фирме работать, если других предложений нет (да студентов берут часто не охотно). Но вы предлагаете выпускнику идти целенаправлено в болото?
А зачем работать эникейщиком? Руки марать в пыли? К моменту поступления в институт я уже хорошо программировал. Лучше, чем 80% выпускников этого же ВУЗа. Но обучался-то один. Инет появился поздно. Книжка Попова по паскалю и дельфи-хелп + позже мсдн с msvs 2006-2008 где-то урвал. По ним и учился. Были еще книжки что-то в духе 50 приемов чего-то там от Майерса.
Маленькая зарплата — это так же и возможности. Просто взять и например послать начальника в пешее путешествие. Взять и сделать по своему… и еще и оказаться правым. Что бы управлять людьми не обязательно быть руководителем. Хотя по началу я себя очень скромно вел. Очень. Пока не начал понимать что к чему и как да почему.
Кому болото — трата времени и сил, а кому песочница, которую будешь крутить как захочешь (денег же не платят, а люди пассивны довольно, кроме слов и ругани ничего не сделают). Да — ненависти огребешь по полной. Но увольнять тебя принципиально не будут, причины же очевидны, напротив — с огромным трудом уволишься.
Зато поворошив это все поймешь как оно детально работает и почему (или наоборот почему не работает).
В гугле таких же болот хватает, только там ты будешь винтиком и система в целом сложнее, что бы ее изучать без подготовки. А то и вовсе никогда не поймешь как оно получилось именно так. И потерять можно не 1-2 года, а лет 10.
А прыгать с одной работы на другую, только потому что на новой больше предлагают? Иметь трудовую, забитую под завязку записями в 1 год? Зачем?
Я уже видел резюме людей, у которых 10 раз работа поменялась за 7 лет… Как жить-то, если ты сам болото?
мне не помешало с зп в 30к перейти в коммерцию и зарабатывать 120к.
Тут вопрос что ты делаешь в "болоте", тухнешь или пытаешься что-то изменить. Хотя бы себя.
Но разумеется для каждого свое.
И да, работал в этих предприятиях пока учился.
И вы очень сильно ошибаетесь. Такие же "болота" и в коммерции бывают. Причем чаще, чем кажется и им для этого не нужны приставки "НИИ" или "НИЦ".
Пока устраивался на новую работу повидался за 5 собеседований на эти зоопарки.
для начинающего программиста часто опасно "заразиться" ленью и разгильдяйством
Обычно для этого нужна почва. Сами по себе люди не становятся лентяями и разгильдяями. Если с детства к аккуратности и трудолюбию приучили — избавится сложно.
Я учил многих в коммерческой фирме. Это обычно окупается, так как специалист вырастает во много раз быстрее. Так что сильно зависит от фирмы, в некоторых наоборот будут стараться чтобы не научился, потому что им нужны манкидевелоперы за копейки, а опытных разработчиков хватает.
Проблема в том, что единицы не задают общий формат. А надеяться на чудеса — опрометчиво.
Манкидевелоперы обычно у не очень способных руководителей, коих более чем достаточно. А удержать опытного разработчика бывает сложно.
Вот что бы точно опознавать этих "неспособных" руководителей — и нужно идти работать в НИИ на пару лет, лучше еще во время учебы на полставки — посмотреть на них в живую. Только не надо этого делать с устоявшимся мнением, что там все такие — цель понять как одних от других отделять. Будет ощущение, что потерял время, зато прививка на всю жизнь. С ходу этих "эффективных" будешь распознавать. Это не только куроводителей касается. Вообще всего спектра специальностей ИТ.
А низкая зарплата только в масть в этом случае.
А теперь попробуй в коммерции, когда работать приходится очень много, заниматься такой социальной инженерией. Долго протянешь? Зарплату тебе не за исследование фирмы дают.
Покажется странным, но поработать в НИИ все же стоит. Что бы понимать, как не надо работать. Речь про организационные вопросы и попо-часы.
Очень быстро сдувает все лишние и начинаешь понимать как должно работать предприятие. Особенно когда начнешь пытаться что-то менять и стараться, а все в мусор.
Во всяком случае, если нет никаких менторов адекватных, которые в случае чего объяснят или дурь выбьют, коей во всякой голове достаточно.
И нет, в коммерческой фирме более-менее не научат, а научишься. Нигде тебя особо учить не будут.
Ищите любой проект, который хоть как-то соответствует вашим ожиданиям.
В зависимости от амбиций:
3.1 Переделываете часть проекта как вам нравится — разумеется ничего не получится, но опыта будет выше крыши, гендальф будет отдыхать в сторонке;
3.2 Смотрите багтрекер проекта и исправляете баги.
Как пример, было стремление разрабатывать игры, нашел игру freecol. Так как просто править баги мне наскучило — решил написать свой ИИ к нему, тот что был тогда — так себе, читер и не более того.
Пока писал ИИ нашел несколько интересных багов в серверной части проекта, которые обычным способом найти нельзя, как пример: ИИ высаживал юнит с корабля, понимал, что это не его район и обратно юнит на корабль сажал. Согласно правилам игры так делать нельзя — очков движения не хватит у юнита, а вот сервер разрешал.
ИИ я конечно же не закончил, но он один, сам по себе мог строить колонии и более менее существовать сам по себе. Вроде 1,5 месяца просидел над ним.
И только через год у меня были методы оптимизации в институте, которые бы очень сильно помогли =(
Совет конечно запоздалый, но лучше за время учебы поучаствовать в опенсорсе на сотню-другую часов. Мозги прочищает, да с людьми общаться научишься, чужой код читать и оценивать. Курсы такого не дадут никогда. И главное, что в любой момент можешь уйти. С работой так не выйдет, трудовой договор обе стороны защищает же.
Рекомендую заглянуть сюда: http://asn1-playground.oss.com/
Так и проверял, правильно ли я понял доки. Все интеграционные тесты "а" в бинарном виде получены как раз из этого сервиса.
Основной упор был на поддержку спецификаций (X.680-X.683) для чтения и представления схем в модель. Иначе что-либо делать далее не имеет смысла.
Аннотации в данный момент — рудимент, который нужно будет переписать с нуля. На это дело потрачено часов 10. Для сравнения, суммарно (включая предыдущую попытку, которая так же на гитхабе у меня валяется) на проект ушло более 300 часов.
Что же до генерации бинов — это не такая сложная задача. И ставить себе такую задачу не было желания, т.к. проект мой ничем не отличался бы от уже существующих опенсорсных аналогов.
Проект писался и пишется исключительно по фану и ради удовольствия.
Превосходно. У вас есть GPU (или любой другой специализированный вычислитель) и необходимо решить задачу через матричные вычисления, но у вас же есть "свои" методы, которыми вы успешно решаете на CPU.
Это провал Карл! Ваше решение не оптимально!
Дифуры и физика — это всего лишь инструменты, так же как CPU и GPU. И нужно уметь пользоваться ими, а не показать, какой вы молодец. И замечу — способность видеть множество решений — это только плюс вам. Но решение обязано подпадать под ТЗ. Иначе вы подставляете человека.
Просто подумайте, у вас попросили отмерить 1 метр оптоволокна, но вы решили, что отмерить 2 фута будет проще. Как потом быть заказчику? Смысл именно в инструментах и стандартах.
Это относится к функциональным языкам — у них есть своя специфика, которая и позволяет обходить глобальные состояния… за счет глобальных монад. Да что уж, предлагаю пойти дальше — класс, функция — это тоже глобальный объект, в своем роде. Только вот их глобальность скрыта ЯП и не доступна, обычно, программисту. Хотя умельцы патчат классы в рантайме прямо в виртуалке при загрузке этих классов — AspectJ как пример.
И да, как решение для ликвидации глобального состояния — ФОП отличное решение.
А в остальных случаях как? Или идеализм и перфекционизм вездесущи и все строем должны идти учить хаскель?
Ты решение из другой сферы взял, и при этом не достиг цели.
Вот если бы ты в контексте дифуров придумал свое решение, пусть даже менее элегантное — это было бы круто.
Ваш вариант — это в соревновании бега в мешках пробить в нем дно и бежать.
Решение не подпадает под заданную цель. Считайте это как ТЗ.
В целом же, в абстрактном случае, получи вы такую же задачу с просьбой решить — ваше решение было бы как раз самым правильным, потому что дифуры — это микроскопом гвозди забивать, когда есть более простое и доступное решение.
Где же в вашем первоначальном комментарии "правильно, как учили"?
Не всегда.
Вы представляете себе, чем бы являлись системы логгирования, будь они строго локальны? Т.е. инициализация происходила бы на каждый класс?
Второе имя гениальности — краткость, первое — новизна.
В свое время так же занимался правкой багов во freecol. Одновременно писал к нему новый ИИ, который бы никогда не закончил.
Пока писал ИИ, с его помощью нашел баг в сервере.
В целом помощь в рефакторинге, исправил пару багов в клиенте и один в сервере.
Вроде бы участвовал только пару месяцев, зато очень хорошо помогло войти в курс дела разработки на Java. По времени ушло где-то 80 часов рабочего времени летом, а опыт использую до сих пор.
Если хотите чему-то научиться — ставьте себе невыполнимые задачи и шаг за шагом ее реализуйте. А опенсорс для этого самое лучшее начало. Гнаться за деньгами вот так вот сразу — бесперспективно. В любой области.
Допустим, что убираем checked. Вообще никаких исключений не видно, которые мог бы выбросить фреймворк, например для работы с http.
Что именно ловить? Checked исключения — это вариант возвращаемого значения с приятным бонусом в виде неявного завершения блока кода, вместо проверок возвращаемого методом кода (результата) — ловишь исключение. Это не только код упрощает, но и избавляет от нужды читать список констант (почему все упало) и пользоваться какими-то левыми инструментами, что бы получить детали.
А насчет заворачивания исключений многократно могу лишь сказать так: руки кривые и излишнее проектирование. Не каждый уровень бизнес-логики вообще требует какой-либо работы с исключениями.
Исключения не везде нужны. В лучшем случае в 1% функционала его требует обязательно, все остальное — проектирование ради проектирования.
Вот чего не хватает в Java, так это возможности сказать, что любые исключения в этом методе считать unchecked — как раз избавится от ручного управления списком throws. Современные IDE и компиляторы вполне умны, что бы понять какое исключение может быть в вызываемом методе и передать его выше. Для этого вроде как даже Java Reflections достаточно, информация присутствует.
Но для этого же существует суффикс при определении метода: throws И не нужно тогда ничего обрабатывать, при этом верхние уровни абстракции получат всю информацию о том, что использует ваша библиотека.
Насчет использования исключений в стиле goto не совсем согласен (ошибка 4), есть % тех случаев, которые просто требуют именно выброса исключений.
Как пример: Вы трассируете некую структуру данных (предположительно неограниченную — граф, дерево или список списков) и создаете собственную структуру данных с ограничением: не более N узлов.
Делать постоянные проверки на останов — снижение быстродействия более чем в 10 раз (такой код уже не будет оптимизироваться JIT даже если вы гуру в Java), не говоря о значительной потере читаемости такого кода, в котором везде и всюду if-else натыканы. С исключениями работает почти мгновенно. Разумеется исключение должно при этом иметь адекватное название, например TraceNodeLimitExceededException.
Так что ошибка 4 является ошибкой далеко не всегда.
Правильнее было бы назвать — рекомендация: "Не используйте исключения для управления ходом исполнения приложения, если нет значительной потери в быстродействии или читаемости кода."
Нет смысла лишать себя возможности сразу прекратить выполнение целого блока кода, если это позволит сделать код читаемым и не пестрить везде и всюду проверками.
На эльфах держится Objective-C объектная надстройка.
Асоциальность и не туда затянуть может. Вы недооцениваете степень замкнутости людей и неспособность (нежелание?) понимать окружающих.
Не знаю никаких проблем с самоуважением. А рвать в гугл только ради престижа? Деньги? Иммигрировать? Личная жизнь? Вы о чем?
А зачем работать эникейщиком? Руки марать в пыли? К моменту поступления в институт я уже хорошо программировал. Лучше, чем 80% выпускников этого же ВУЗа. Но обучался-то один. Инет появился поздно. Книжка Попова по паскалю и дельфи-хелп + позже мсдн с msvs 2006-2008 где-то урвал. По ним и учился. Были еще книжки что-то в духе 50 приемов чего-то там от Майерса.
Маленькая зарплата — это так же и возможности. Просто взять и например послать начальника в пешее путешествие. Взять и сделать по своему… и еще и оказаться правым. Что бы управлять людьми не обязательно быть руководителем. Хотя по началу я себя очень скромно вел. Очень. Пока не начал понимать что к чему и как да почему.
Кому болото — трата времени и сил, а кому песочница, которую будешь крутить как захочешь (денег же не платят, а люди пассивны довольно, кроме слов и ругани ничего не сделают). Да — ненависти огребешь по полной. Но увольнять тебя принципиально не будут, причины же очевидны, напротив — с огромным трудом уволишься.
Зато поворошив это все поймешь как оно детально работает и почему (или наоборот почему не работает).
В гугле таких же болот хватает, только там ты будешь винтиком и система в целом сложнее, что бы ее изучать без подготовки. А то и вовсе никогда не поймешь как оно получилось именно так. И потерять можно не 1-2 года, а лет 10.
А прыгать с одной работы на другую, только потому что на новой больше предлагают? Иметь трудовую, забитую под завязку записями в 1 год? Зачем?
Я уже видел резюме людей, у которых 10 раз работа поменялась за 7 лет… Как жить-то, если ты сам болото?
мне не помешало с зп в 30к перейти в коммерцию и зарабатывать 120к.
Тут вопрос что ты делаешь в "болоте", тухнешь или пытаешься что-то изменить. Хотя бы себя.
Но разумеется для каждого свое.
И да, работал в этих предприятиях пока учился.
И вы очень сильно ошибаетесь. Такие же "болота" и в коммерции бывают. Причем чаще, чем кажется и им для этого не нужны приставки "НИИ" или "НИЦ".
Пока устраивался на новую работу повидался за 5 собеседований на эти зоопарки.
Обычно для этого нужна почва. Сами по себе люди не становятся лентяями и разгильдяями. Если с детства к аккуратности и трудолюбию приучили — избавится сложно.
Проблема в том, что единицы не задают общий формат. А надеяться на чудеса — опрометчиво.
Манкидевелоперы обычно у не очень способных руководителей, коих более чем достаточно. А удержать опытного разработчика бывает сложно.
Вот что бы точно опознавать этих "неспособных" руководителей — и нужно идти работать в НИИ на пару лет, лучше еще во время учебы на полставки — посмотреть на них в живую. Только не надо этого делать с устоявшимся мнением, что там все такие — цель понять как одних от других отделять. Будет ощущение, что потерял время, зато прививка на всю жизнь. С ходу этих "эффективных" будешь распознавать. Это не только куроводителей касается. Вообще всего спектра специальностей ИТ.
А низкая зарплата только в масть в этом случае.
А теперь попробуй в коммерции, когда работать приходится очень много, заниматься такой социальной инженерией. Долго протянешь? Зарплату тебе не за исследование фирмы дают.
Покажется странным, но поработать в НИИ все же стоит. Что бы понимать, как не надо работать. Речь про организационные вопросы и попо-часы.
Очень быстро сдувает все лишние и начинаешь понимать как должно работать предприятие. Особенно когда начнешь пытаться что-то менять и стараться, а все в мусор.
Во всяком случае, если нет никаких менторов адекватных, которые в случае чего объяснят или дурь выбьют, коей во всякой голове достаточно.
И нет, в коммерческой фирме более-менее не научат, а научишься. Нигде тебя особо учить не будут.
3.1 Переделываете часть проекта как вам нравится — разумеется ничего не получится, но опыта будет выше крыши, гендальф будет отдыхать в сторонке;
3.2 Смотрите багтрекер проекта и исправляете баги.
Как пример, было стремление разрабатывать игры, нашел игру freecol. Так как просто править баги мне наскучило — решил написать свой ИИ к нему, тот что был тогда — так себе, читер и не более того.
Пока писал ИИ нашел несколько интересных багов в серверной части проекта, которые обычным способом найти нельзя, как пример: ИИ высаживал юнит с корабля, понимал, что это не его район и обратно юнит на корабль сажал. Согласно правилам игры так делать нельзя — очков движения не хватит у юнита, а вот сервер разрешал.
ИИ я конечно же не закончил, но он один, сам по себе мог строить колонии и более менее существовать сам по себе. Вроде 1,5 месяца просидел над ним.
И только через год у меня были методы оптимизации в институте, которые бы очень сильно помогли =(
Совет конечно запоздалый, но лучше за время учебы поучаствовать в опенсорсе на сотню-другую часов. Мозги прочищает, да с людьми общаться научишься, чужой код читать и оценивать. Курсы такого не дадут никогда. И главное, что в любой момент можешь уйти. С работой так не выйдет, трудовой договор обе стороны защищает же.
Рекомендую заглянуть сюда: http://asn1-playground.oss.com/
Так и проверял, правильно ли я понял доки. Все интеграционные тесты "а" в бинарном виде получены как раз из этого сервиса.
Аннотации в данный момент — рудимент, который нужно будет переписать с нуля. На это дело потрачено часов 10. Для сравнения, суммарно (включая предыдущую попытку, которая так же на гитхабе у меня валяется) на проект ушло более 300 часов.
Что же до генерации бинов — это не такая сложная задача. И ставить себе такую задачу не было желания, т.к. проект мой ничем не отличался бы от уже существующих опенсорсных аналогов.
Проект писался и пишется исключительно по фану и ради удовольствия.