Pull to refresh
19
0
Send message

А почему брали девятую джаву

В комменте ошибся, сейчас посмотрел - 11-я. Но посыл был в том, что "уже не восьмая" :)

Тоже в январские каникулы начал писать свой десктопный пет-проект на Java 9 - JavaFX вполне себе живее всех живых, использовал в связке с MvvmFx. Написал бОльшую часть функционала, но когда дошла речь до упаковки - просто ступор.

Сначала решил пойти путём "by design" и использовать jlink, надеясь на выходе получить красивый дистрибутив с кастомной JRE - в конце концов, именно для этого он и был придуман. Возможно, я неправильно их готовил, но, по моему опыту, модули из Java 9+ - это тихий ужас, когда в проекте много сторонних библиотек. Самый главный вопрос, который меня мучал - сколько еще, блин, раз я должен описывать свои зависимости? В pom.xml укажи, в module-info укажи, в аргументах jlink укажи. Что характерно, дистрибутив так и не собрался - где-то там в глубинах окопался автоматический модуль, работать с которым jlink отказался. Короче, бросил я этот кактус, и стал смотреть в сторону fatjar (господи, fatjar в 2022 году, классика не устаревает). Честно говоря, результаты меня тоже не очень удовлетворили - как по размеру, так и по процессу сборки.

Посмотрел я на свою коровенку и понял, что она в текущем виде предназначена для работы исключительно под Windows (там используются голосовые функции, которые, к сожалению, после долгого мучения с MaryTTS и CMUSphynx, пришлось реализовать в виде работы с Windows Speech API через прокси), поддержки ни Linux, ни мобильных OS не требуется (в виду специфики продукта).

И перетащил все на C# + WPF, благо бОльшая часть логики и тестов переносятся практически буквально (языковые конструкции отличаются в основном синтаксисом, stream API -> Linq, naming conventions поправляются IDE). Процесс перевода core занял один вечер, собственно, основное время заняло переписывание UI - давно я с WPF не работал, но в целом, процесс тоже не сложный. IDE - пересел с Jetbrains IDEA на Jetbrains Rider, в целом безболезненно.

Пока не жалею. WPF по функционалу - гораздо гибче JavaFX, хотя, конечно, не без нюансов. Практически все аналоги нужных библиотек имеются. Работа с Windows Speech - из коробки. Exe на выходе - из коробки.

Именно — это и есть трактовка результатов эксперимента :) Обычно, формулировку исходной гипотезы постепенно сужают (где-то на днях видел картинку: теория всего => теория чего-то => теория ничего), и это и есть суть научного поиска.


Правда, при публикации результатов в популярном виде, журналисты обычно краевые условия для краткости и пущей важности опускают и вместо "у новорожденных детей в возрасте от 45 минут до 72 часов наблюдается статистически значимая корелляция между собственными мимическими действиями и мимическими действиями, демонстрируемыми взрослым объектом" получаем "младенцы младше часа от роду уже высовывают язык вслед за папой и мамой" — даже, если таковой младенец в положительных результатах был всего один :)

Нормально описываю, антивакцинщикам назло :)


Все, к сожалению, гораздо сложнее. Результаты "примитивного" эксперимента можно трактовать очень по-разному.


Может быть, данный конкретный младенец так реагирует на данное конкретное лицо — просто потому, что нейрончики так сцепились? Может быть, во время открывания рта взрослый рефлекторно нажимал на ребенка или тот реагировал не на какой-то другой фактор (хотя бы — запах изо рта)? Может быть, экспериментатор принял шевеление губ ребенка за высовывание языка и, желая успешно отчитаться, поставил плюсик там, где не надо? И куча других вопросов и побочных факторов, множество из которых субъективны.


Поэтому эксперимент нужно ставить на многих младенцах, разных возрастов, рас, полов и т.п. и с которыми работают разные взрослые — мужчины, женщины, старые, молодые. И контакт между ними исключить до только визуального (например, прозрачная ванна с крышкой). Крайне желательно при этом применять "двойной слепой метод" (см. https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D0%B5%D0%BF%D0%BE%D0%B9_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4) — т.е. оказывается, что два независимых ракурса, как раз-таки, обязательны — одна камера снимает малыша, одна камера снимает взрослого. Потом при расшифровке независимое лицо пишет — на 0:35 секунде ребенок открыл рот, на 0:48 — высунул язык, а другой — делает то же самое с записью взрослого.


И только потом, когда все эксперименты окончены, все результаты сводятся в одну таблицы и, собственно, экспериментатор начинает их смотреть и пытаться как-то трактовать результаты.

Оба варианта неправильные, когда речь идет о науке. Верить лучше результатам правильно поставленного эксперимента, опубликованным в рецензируемом научном журнале с хорошей репутацией, желательно воспроизведенном независимыми исследователями.


Справедливости ради стоит отметить, что эксперимент Мелцоффа (Andrew N. Metlzoff) не является стопроцентным фактом, и в некоторых исследованиях не воспроизводился.


https://en.wikipedia.org/wiki/Intermodal_mapping — см. разделы Criticism и Replication

Все новое — это хорошо и основательно забытое старое. Обзор методов эволюции нейронных сетей — я эту статью написал 9 лет назад, картинок там, к сожалению, нет, зато есть описание и сравнение разных подходов.
Кстати, NEAT был предложен еще в 2002 году и потом еще дорабатывался (в частности, есть его вариация HyperNEAT).

Вытеки мои глазоньки… Действительно, решение — «оригинальное» — в том смысле, что второго такого вряд ли найдете. Если целью учебного задания было научить вас работать со строками и стандартными структурами данных в C#, то, наверное, все ок, а если — научиться писать парсер, то так парсер не пишется.

Вы допустили несколько ошибок — методологических в основном.

1. Любой парсер начинается с юнит-тестов! Для начала хотя бы пары выражений, но в идеале — чем больше, тем лучше. Потратьте полчаса времени придумывая самые извратные варианты — потом это окупится с лихвой.
2. За юнит-тестами идет грамматика. Честно говоря, я был удивлен, не увидев её в статье — может, вам её уже дали в условиях задания? Если нет — обязательно нужно описать грамматику и отладить её на юнит-тестах — в инете есть для этого средства, ну или написать свои.
3. Далее — лексер. Он разбивает выражение на токены, затем парсер работает уже с ними. Одновременно токенизировать и парсить как минимум неудобно.
4. Наконец — сам парсер. Изобретать велосипед — дело, конечно, интересное, но в вопросе парсинга математических выражений — мягко говоря, неблагодарное. Все уже было украдено до нас. Задолго. Просто реализуйте алгоритм рекурсивного спуска или сортировочной станции и радуйтесь результату.
А потом приходит Роскомнадзор и блокирует адреса из пула AWS…
Есть отличная статья 1986 года — No Silver Bullet, в которой все это описано и расписано, почему это так. Единственное, что в ней устарело — это названия конкретных технологий, но если заменить Ada на какой-нибудь Scala, ООП — на микросервисы, а искусственный интеллект — на machine learning, её суть практически не меняется

Ну, появление автомобилей не убило же беговые виды спорта.


Более того, такие продвинутые боты могут помочь повысить результаты обычными соло-игрокам — как минимум, в виде возможности тренироваться против конкретных адекватно играющих чемпионов на линии, а в будущем — и в тим-файтах

Да уж, да ещё и с блок-схемами, инфографикой и видюшкой на ютюбе.


Помнится, нам на первом курсе препод сказал — вот рекурсия, вот пример, вот бест-практис — первой инструкцией писать выход из рекурсии — и, собственно, все.

Выходит, что универсальная теорема аппроксимации действительно верна

А разве ее не доказал Цыбенко еще в 1989 году?

В целом, пока пока статья смотрится бледновато — особенных глубин понимания не продемонстрировано. Настоятельно рекомендую посмотреть на курсере курс Machine Learning стэнфордского университета, хотя бы первые 4 недели курса. Там буквально на пальцах разжевывается суть задачи приближения функции и то, как она связана с нейронной сетью. В частности, там вы узнаете, почему добавление весового нейрона улучшает сходимость, в чем прелесть нормирования входных данных, и как можно строить нелинейные приближения, используя линейную функцию активации
Вообще-то, по канону, кроме сроков, РП еще должен управлять качеством и бюджетом, а иначе дисбаланс возникает.

И в целом, основная задача менеджера проектов уж никак не тайм-менеджмент и уж точно не теребить каждые три часа разработчика, а выстраивать и обеспечивать эффективные коммуникации. И тогда и инфа о статусе задач будет у того, у кого нужно и тогда, когда нужно, и требования будут будут пониматься однозначно, да и оценки сроков будут реалистичные.

З.Ы. Я лично всегда воспринимаю необходимость овертаймов — как личный факап РП
Раз уж вы опубликовали пост в хабе Управление, хотелось бы задать пару уточняющих вопросов управленческого характера.
1. Какая самая высокая высокая должность была среди тех, кого вы уволили?
2. Кроме автоматизации и внешнего контроля качества, что изменилось в плане отношения рядовых сотрудников к качеству выполняемых работ? Поясню вопрос — операционный директор и куэйщики принципиально способны отловить ошибки только по истечении определенного времени после ее появления, возможно, когда клиент уже в курсе и осадок остался. Кроме того, наличие специальных внешних людей, отвечающих за качество (да еще и в таком количестве), подсознательно может восприниматься как расслабляющий фактор — есть кому ошибки искать и без меня. Что поменялось на уровне рядовых исполнителей?
3. Про кнут вы написали в целом понятно. А пряники были? Или наградой здоровой части коллектива за хорошую работу было повышение нагрузки за счет перераспределения работ ушедших?
По-моему, акценты расставлены не совсем верно, хотя по сути выводы и рекомендации верные. Управление проектами в IT, как и в любой подобной сфере, это управление (по убыванию важности) а) рисками, б) коммуникациями, в) ожиданиями заказчика. Все остальное — в т.ч. методологии разработки, жизненные циклы и пр. — всего лишь

Управление рисками означает заранее знать и понимать, что может пойти не так, где, почему и, соответственно, принимать либо упреждающие, либо корректирующие воздействия. Соответственно, без знания специфики и нюансов IT-разработки тут делать нечего — неофит будет просто не знать, что именно может пойти не так.

Управление коммуникациями — это вообще классика (см. известную картинку с качелями «Как хотел заказчик»). Если не знать, где и почему один член проекта может не так понять другого — опять же ничего не сделаешь.

И только управление коммуникациями более-менее нормально ложится на предыдущий опыт — естественно, если он из хотя бы как-то приближенной сферы.

Поэтому, лично мне видится единственная рекомендация — роль помощника PMа или аналогичная. Покрутиться на проектах, посмотреть как дела делаются и что может идти не так — и уже после этого думать о соло.
Господи, детский сад, ясельная группа.
Даже и не знаю, что ответить. Из серии «Солженицина я не читала, но я бы первая прибила его к позорному столбу». Просто без комментариев.
Хороший вопрос. Поясняю.
ФОТ не задает какие-то «рамки» зарплаты, он задает верхнюю сумму з.п. всему подразделению в год. Если у меня в середине года освобождается позиция, допустим, в 100 тыс. руб., это значит, что в ФОТе появляется пространство для маневра примерно на 600 тыс. руб. (з.п. за полгода). В эти 600 тыс. руб. я могу вместить одного хорошего программиста (с учетом того, что на поиск уйдет один-два месяца его з.п. может быть даже выше, чем 100 т.р.), а могу двух младших. Есть вариант нанять одного середнячка, а остаток суммы потратить на увеличение з.п. кому-то из имеющихся сотрудников. На деле вариантов еще больше (может, у меня на данный момент разработчиков вообще переизбыток, а тестировщиков не хватает).

И, кроме того, опять же дилемма ценника — если я сразу вывешу в вакансию, допустим, верхнюю планку з.п., то могу получить в потоке соискателей неплохую пачку тех, кто просто «на шару» пытается попытать счастья — вдруг пройдет. Не говоря уже о том, что я могу ошибиться и принять на работу человека, который может согласиться работать за более низкую з.п. — т.е. переплачу и, в результате, ФОТ будет расходоваться неэффективно.
Так я и ни слова не говорил про иерархию. Вы абсолютно правы — категории «выше-ниже» — это не о рыночной экономике. Просто есть разные модели рыночных отношений, в которых стороны ведут себя по-разному — и если две стороны используют разные модели, то возникает конфликт понятий, который нужно разруливать, прежде чем двигаться дальше.

Сложно играть, если одна сторона играет в шашки, а другая — в нарды. И я имел в виду только это.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity