прогеры: ММ или ВМиК?

Werdna

Холиварный топик, кто? Какой процент хороших? Какой процент совсем в сторону сзм? Кого бы предпочли взять на работу, мм или вмк?

salamander

Слишком толсто.

Dasar

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

luna89

Я ВМК, сзм, на работу не брать.

apl13

мехмат - бизнес-алкоголик

Werdna

вмк - это уже скорее архитектор или старший шаман
Хороший архитектор — строго не шаман, но это моё мнение. Вообще, шаманство я считаю наебкой работодателя. Либо ты делаешь на совесть, как можешь, либо постоянно что-то костылями правишь и шаманишь, и без тебя хз что будет.
А вот шаманство как раз вмк-шный признак. Мехмат более склонен выяснить все детали и сделать очень ответственно, вникнув во все мелочи.
В то же время вмк-шник может по-быстрому набрать кучу говна и заставить хоть как-то работать. Мехмат скорее пошлёт с этой кучей говна куда подальше.

spitfire

по-быстрому набрать кучу говна и заставить хоть как-то работать
В моей выборке мехмат за таким занятием был замечен в равной степени. Дело не в факультете.

Werdna

Интересно процентное соотношение и репрезентативность выборок. :)

domovoj

Какая нахуй репрезентативность, вы хоть с критерием и уровнем значимости определитесь.
И гипотезу нормально сформулируйте!

zya369

да что там вмк, вон пианист даже форум не смог собрать :(

svetaslav212

прогеры: ММ или ВМиК?
ХимФак. :( :mad:

Werdna

Заминусовали, демоны! :)

erotic

Мне физики нравятся в этом плане.

bav46

главное не брать пианистов

2897335

Какой процент совсем в сторону сзм?

Это ты намекаешь, что у тебя в конторе карты написаны так, что ими пользуются только из-за того, что тот, кто писал, хорошо знал местность, а о usability и дизайне не подумал, поэтому получилось квадратно-гнездовым, по сравнению с конкурентами? Тебе морду надо начистить на петровско-разумовской, чтобы ты поменьше троллил.
У мм профиль шире, но дегенератов вроде тебя и там хватает. Я бы тебя не взял. Из-за упоротости.

Werdna

ого, нифига себе что бывает, если человек забывает принять прописанное доктором препаратики...

stm6692945

Имхо Вмк
но не изза того что там лучше учат. А просто на мехмате больше людей с завышенным чсв, что они мега ученные.
Чтоб стать норм программистом надо чтобы тебе ставили сложные задачи, без подсказок как ее осуществлять и реалистичным сроком.
Те если бы учили так:
"Вот тебе задача на неделю, я сам не знаю как делать ее , читай, делай, срок неделя"
То из таких людей ковались бы мега программисты.
Не на мехмате и вмк так не делают.
Имхо главное в программисте не знание, а способность находить и решать задачу.

tucha96

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

Werdna

Имхо главное в программисте не знание, а способность находить и решать задачу.
Вброс: на мехмате _НЕ_ дают вообще знаний в том смысле, как это делают на ВМиК и тем более в других вузах. Максимум чему учат — каким-то азам, и то, скорее просто дают методичку и направление куда копать. Стандартный мехматянин, вообще говоря, — это просто прокаченный мозг, который на порядок меньше знает выпускника кулинарного, но именно этот мозг может весь курс кулинарного заботать быстренько.
На ВМиК же существенно меньше идёт тренировки мозга, и гораздо больше дается знаний. Хорошо, если это — знания «академического типа», чаще же всего прошивают прямо в мозг конкретные технологии. Весьма распространён вариант, когда впариваются технологии устаревшие или откровенно хреновые, но нравящиеся конкретному преподу. Вместе с этим сеют наборы стереотипов и просто дурновкусие, после которого вроде как свеженький вьюноша уже перестаёт воспринимать что-то другое.
Может ли у чела с ММ быть привито дурное? Да, запросто, но это уже прививается или на первой работе, или от товарищей. Сами факультетские курсы вообще ничего не "продают", по сути являясь максимально абстрагированными от любой идеологии.
В то же время, стоит отметить, что стандартные на 1-2 курсе прогерские предметы на ВМиК — очень хорошие. Я о курсе алгоритмов с Паскалем, ассермблере и системном прогании. Но, к сожалению, посеянное доброе-вечное затем зарастает сорняками. Как итоге — вмк-шник запросто завалит вопросы типа "какая сложность у такого-то запроса" по своей любимой БД, но зато бодро будет вещать про абстрактный маппинг объектов в его любимом ORM.

stm6692945

тя послушаешь так на мехмате только мозг качают решая познавательные и развивающие задачи
от моих знакомых кто учился там я знаю, что там такоеже впихивание теорем как и везде
и развивающими задачами и не пахнет
как к примеру в ЗФТШ (кто учился)

Werdna

там такоеже впихивание теорем как и везде
Математику правильно впихивают, собственно об этом факультет, чем ты не доволен?
познавательные и развивающие задачи — это этап мат. школы, и олимпиад. На мехмат уже приходят с этим багажом.

6yrop

познавательные и развивающие задачи — это этап мат. школы, и олимпиад
а должна быть вся жизнь

stm6692945

Математику правильно впихивают, собственно об этом факультет, чем ты не доволен?
ну математику впихивают на мехмате , вмк, физфаке
почему ты считаешь что именно на мехмате ее впихивают правильно

luna89

Я о курсе алгоритмов с Паскалем, ассермблере и системном прогании.
Алгоритмы с Паскалем был вообще единственным курсом, который я не считаю потраченным временем. Реально крутой курс. К сожалению, дальше курсы были какие-то бестолковые. Я бы на второй семестр поставил какой-нибудь питон, чтобы студенты были в состоянии хоть что-то запрогать (а то получается, что отучившись год, студенты способны кодить только в турбопаскале). Тогда бы и C в третьем семестре хорошо бы пошел. C++ в четвертом надо вообще выбросить.

Werdna

почему ты считаешь что именно на мехмате ее впихивают правильно
а где я такое утверждал? речи про математику не было.
топик о том, откуда какие прогеры, у кого какие мнения.

6yrop

Стандартный мехматянин, вообще говоря, — это просто прокаченный мозг,
"Мехматянин — прокаченный мозг" это у вас там местная байка (шаблон) на факультете такая? Просто я ее несколько раз уже слышал от разных мехматян. Не мог бы ты развернуть понятие "прокаченный мозг"? Это быстро заботать курс кулинарного? Т.е. прокаченный мозг это способность быстро воспринимать шаблоны и жонглировать ими?

Papazyan

Прокачанный мозг - это хорошая память.

6yrop

Прокачанный мозг - это хорошая память.
Дейкстра говорит, что лучше научиться жить с маленьким размером человеческой головы:

Summarizing: as a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure.
http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF

Это как соревноваться качку с подъемным краном.
Главная отличительная черта хорошего программиста это способность к построению хороших абстракций:

Все мы знаем, что единственный умственный инструмент, посредством которого весьма ограниченный разум может охватить мириады различных вариантов, называется «абстракцией»; в результате эффективное использование мощи абстракции должно расцениваться как одно из наиболее жизненно важных действий компетентного программиста
http://club.shelek.ru/viewart.php?id=155
 

Кстати, у филологов тоже неплохая память.

svetaslav212

(а то получается, что отучившись год, студенты способны кодить только в турбопаскале)
Умея кодить в турбопаскале, можно успешно кодить в дельфях и фрипаскале. А это уже что-то.

luna89

Умея кодить в турбопаскале, можно успешно кодить в дельфях и фрипаскале. А это уже что-то.
Проблема в библиотеках.

Anturag

Главная отличительная черта хорошего программиста это способность к построению хороших абстракций
Кто как не математики имеют способность к построению абстракций и оперированию символьными данными.

6yrop

Кто как не математики имеют способность к построению абстракций и оперированию символьными данными.
Далеко не все могут вырабатывать хорошие абстракции. Ты не путай выработку абстракций и работу с абстракциями. Все математики работают с абстракциями, но не факт, что все могут их производить.

Werdna

Далеко не все могут вырабатывать хорошие абстракции.
И при этом каждый второй — гениальнейший проектировщик структуры классов! :)
Каждый третий — проектировщик структуры БД!
И лишь каждый сотый включает мозг и задает вопросы, касающиеся производительности, потребления ресурсов, времени отклика. И он-то меньше всего лезет с темой гениальной структуры классов и ORM! :)

Anturag

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

6yrop

И лишь каждый сотый ... задает вопросы, касающиеся производительности, потребления ресурсов, времени отклика.
Тут говорят, наоборот, многие заморочены на это:

Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines....
http://en.wikipedia.org/wiki/Ruby_%28programming_language%29...

Чья статистика верна на 146%?

Werdna

Ну и в итоге получаем тормозное Руби. ;)
Фигня в том, что надо не что-то одно делать, а сразу в комплексе задачи решать. А упоротые любители синтаксического сахара никогда не смотрят на то, что программу в итоге будет выполнять ЭВМ.
Никто не мешает писать понятно для человека, и думать в этом направлении. Не надо только в жертву приносить всё остальное.

yroslavasako

А упоротые любители синтаксического сахара никогда не смотрят на то, что программу в итоге будет выполнять ЭВМ.
а вот авторы SICP говорят, что программы созданы для чтения людьми, а не машинами

6yrop

Ну и в итоге получаем тормозное Руби.
Ты сам на чем и что пишешь?

Werdna

программы созданы для чтения людьми, а не машинами
Программы созданы для выполнения машинами, но должны быть понятны людям.
Кстати, гениальные штуки как раз очень гармонично сочетают в себе всё. А бездарности рождают всякие Явы, которые обжираются ресурсами, и по сути принесли в индустрию извращенно длинный стиль писанины. Ибыточный настолько, что без вспомогательных средств в виде кодогенераторов и комплишенов не получится даже писать программы, просто набивать код задолбаешься.

Werdna

Ты сам на чем и что пишешь?
На разном, могу оценку так дать:
1. Питон — удобно писать, код прозрачный, выполняется предсказуемо на троечку, но язык высокого уровня. Разумеется, джанго — невероятная срань, использовать которую нельзя, но есть в питоне куча хороших библиотек.
2. ПХП — хорошая производительность, жутко сложно писать прозрачный код, сам язык провоцирует на говнокодинг. В целом, для веба остается лучшим языком, кто бы что ни говорил.
3. Чистый Си. Пишу библиотеки всякие, которые использую из плюсов. По сути — это современный ассемблер, но писать на нём легко и приятно, если знать как.
4. Плюсы — всем хорош, но для разработки веб-интерфейсов не использую.
5. mysql — хорошая база данных, но только пока видишь её снаружи. В сам код лучше не залезать. Предсказуемая, известно почти всё, что надо для стабильной работы.
6. mongodb — прекрасная штука, но есть претензии к используемому дисковому пространству. Есть подозрение, что писали очень неэффективно внутри, но что делать — это лучшее, что есть с автоматическим шардингом.
7. javascript в браузре. Мне нравится этот язык, нравится библиотека jquery. Всё достаточно удобно и работает относительно шустро.
Куски говна:
1. Ява
2. Хадуп
3. Флэш
4. Сишарп
5. Сильверлайт
6. Эрланг — это вообще порождение воспалённого сознания
7. визуал бейсик

psm-home

Эрланг — это вообще порождение воспалённого сознания
а кстати почему? вот питон, сишечка и похапе ок, а эрланг не угодил. синтаксис стремный и строки через жопу, а что ещё?

Ivan8209

> Кстати, гениальные штуки как раз очень гармонично сочетают в себе всё.
> А бездарности рождают всякие Явы, которые обжираются ресурсами,
> и по сути принесли в индустрию извращенно длинный стиль писанины.
Не надо тут "ля-ля", ява офигенно хорошо спроектированный язык,
в отличие от всяких тормозных и убогих питонов и пыхпыхов.
А стиль диктуется задачами. Если бы в питоне можно было
заставить индусов писать более корректный код, для разбора
которого не требуется смотреть всю программу целиком,
то и там пришлось бы писать длинно.
---
"Люди недалёкие обычно осуждают всё, что выходит за пределы их понимания."

digenet

"Only ugly languages become popular. Python is the one exception" — Donald Knuth

Werdna

эрланг не угодил. синтаксис стремный и строки через жопу, а что ещё?
синтаксис пофиг.
функциональный он, а процессор ориентирован на процедурность. конечно, как машины Тьюринга они эквивалентны, но вот стоимость этой эквиваленции как раз очень высокая.
Поэтому всё на Эрланге будет работать заведомо хуже, чем на других языках, которые больше к архитектуре приспособлены.

Werdna

ява офигенно хорошо спроектированный язык, в отличие от всяких тормозных и убогих питонов и пыхпыхов
Пыха быстрый как понос, и вообще пыха — только для веба.
А вот на Яве веб пишут только совсем ублюдки. Достаточно посмотреть Джиру — образец тормоза. Тот же трак на Питоне просто летает в сравнении с Джирой. :)

Ivan8209

> функциональный он, а процессор ориентирован на процедурность. <...>
> Поэтому всё на Эрланге будет работать заведомо хуже,
> чем на других языках, которые больше к архитектуре приспособлены.
После таких заявлений с тобой вообще бессмысленно разговаривать на эти темы.
---
"Люди недалёкие обычно осуждают всё, что выходит за пределы их понимания."

psm-home

А вот на Яве веб пишут только совсем ублюдки.
Ява просто традиционно ЯП для энтерпрайза, там веб делают по остаточному принципу обычно. Типа, чо, фронтенд-разработчик? Это кто такой, не, не слышал. А так особой проблемы нет, точно также как в пыхе можно взять простейший шаблонизатор (freemarker какой-нибудь взять голимое JDBC для доступа к БД, легкий http сервер, типа jetty. И будет не хуже, чем на PHP. Сама по себе JVM штука вылизанная и быстрая. Да, память оно конечно ест, но она сейчас дешевая. Просто так обычно на яве не пишут, не та культура, но тут дело не столько в языке, сколько в людях.

Werdna

Просто так обычно на яве не пишут, не та культура, но тут дело не столько в языке, сколько в людях.
Культура вообще у явы особая, это раковая опухоль.

psm-home

раковая опухоль
Ну есть немного, сейчас вот сижу и удаляю-удаляю-удаляю из проекта классы. Оверинжениринг в полный рост, плюс много-много особой уличной магии. Мантра про явное, которое лучше, чем неявное тут не в почете. Это все зависит от точки зрения ещё, кто-то из коллег скажет, что я мудак, там мол был задел на будущее развитие и гибкость, а я всю красоту похерил и налепил ad hoc-ов.

Werdna

кто-то из коллег скажет, что я мудак, там мол был задел на будущее развитие
Ну да, пишут решение задачи, которую ещё не придумали.

Ivan8209

> там мол был задел на будущее развитие и гибкость
А ты уверен, что там действительно не было задела на развитие?
В отличие от питона, где принято лепить код, как на перле,
в яве как раз принята дисциплина программирования. Ты вот сейчас
поудаляешь, потом придёт какой-нибудь индус и вместо того,
чтобы вставить части из удалённого, напишет какой-нибудь бред,
который потом придётся переделывать долго и мучительно.
---
"Narrowness of experience leads to narrowness of imagination."

psm-home

ты уверен, что там действительно не было задела на развитие?
Конкретно в этом случае я уверен. Иначе не махал бы шашкой. А вообще это интересный вопрос, как научиться надежно отличать одно от другого. Хотел бы я так уметь.
Собственно я режу-то почему, потому что код написан очень сложно без причины. Там все такое асинхронное, ни слова в простоте, JMS очереди повсюду, прекрасные FSM на мешанине из if-ов и try/catch, 3 слоя абстракции над БД, одновременно pessimistic и optimistic locks и это ничем не мотивировано. Ну вот буквально: "почему собака лижет яйца - потому что может". А я считаю что простые вещи должны делаться просто, для сложности должна быть причина, для лишних строк кода должен быть мотив. Нет его, не можешь объяснить, какие выгоды сулит посылка сообщения, вместо простого obj.method ну и значит я выкидываю все эти умствования.

Ivan8209

> Нет его, не можешь объяснить, какие выгоды сулит посылка сообщения,
> вместо простого obj.method ну и значит я выкидываю все эти умствования.
Вот это вообще бред. Доказывать надо как раз противоположное:
что посылку сообщения и ожидание ответа можно заменить,
так как "obj.method" это грязный хак для оптимизации.
Он, в частности, прячет проблемы синхронизации, так как
неатомарность "obj.method" воспринимается при чтении хуже,
чем раздельная отсылка и получение ответа. А когда проблемы
обнаружатся, придётся делать ещё один тип, который будет
превращать этот хак в правильную посылку. В итоге
вместо правильного употребления общего механизма
будет употреблён он же, но с промежуточным шагом.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."

6yrop

задела на развитие?
ReSharper всё сделает когда придет время
 

Ты вот сейчас
поудаляешь, потом придёт какой-нибудь индус и вместо того,
чтобы вставить части из удалённого, напишет какой-нибудь бред,
который потом придётся переделывать долго и мучительно.
 

от таких всё равно не застрахуешься, все же куски заранее не напишешь

Ivan8209

> ReSharper всё сделает когда придет время
Да-да, какой-то инструмент, который преобразовывает код
неустановленным образом, магически приведёт код в соответствие
с первоначальным замыслом.
> от таких всё равно не застрахуешься, все же куски заранее не напишешь
Когда продумывается продукт, уже обычно ясно, что, где и как
можно будет расширять. Это всякие питонщики и перловщики готовы
переписывать всё постоянно, как только чуть-чуть требования
поменяются.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."

6yrop

Когда продумывается продукт, уже обычно ясно, что, где и как
можно будет расширять.
о расширении даже думать не надо, пустая трата усилий и времени. Реализовывай текущие требования.
 

 Это всякие питонщики и перловщики готовы
переписывать всё постоянно, как только чуть-чуть требования
поменяются.
 

Конечно, они даже вызовы метода не могут найти, как тут недавно писали.

Ivan8209

> о расширении даже думать не надо, пустая трата усилий и времени.
> Реализовывай текущие требования.
Да-да, "урвать и убежать," "после нас хоть потоп" --- узнаю перловщиков.
"Текущие требования" составлены, как правило, с учётом того, что потом,
на следующем этапе придётся реализовывать настоящие "текущие требования,"
а не то, насчёт чего договорились на текущий этап. В мире явы принято
думать чуть дальше сегодняшнего дня, так как программу будут ещё
и запускать, а не положат пылиться в репозиторий.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."

psm-home

О нет. :) Ты сейчас теоретизируешь. Да, дизайн, основанный на посылке сообщений, может быть офигенен. Там где это так или иначе встроено в язык или есть удобные выразительные средства. В clojure или erlang и много еще где, да хоть ObjC. Ты игнорируешь синтаксический оверхед посылки сообщений в яве. Особенно роскошно это было сделано в моем проекте. Вместо
method {
 ojb.method2;
}
мы имеем КакаяТоХерняService.method ->КакаяТоХерняServiceSender.sendJmsMessage (тут перепаковка параметров в сообщение)->JMS очередь->КакаяТоХерняListener (тут распаковка сообщения в параметры)->КакаяТоХерняService.method2.
Это не Erlang и не scala actors. Это намного, намного многословнее. И главное, в этом нет смысла (конкретно в моем случае). Не, ну давайте на всем пути выполнения заменим линейный вызов метода на посылку сообщений в таком стиле. И застрелимся это понимать и тестировать.

6yrop

Вот так пишут мега архитекторы с заделом на будущее (ref):

class CustomerMapper
def find name
result = nil
sql = 'SELECT * FROM customers WHERE name = ?'
return load($dbh.select_one(sql, name
end
def load row
result = Customer.new(row['customerID'], row['NAME'])
result.orders = OrderMapper.new.find_for_customer result
return result
end
end

class OrderMapper
def find_for_customer aCustomer
result = []
sql = "SELECT * FROM orders WHERE customerID = ?"
$dbh.select_all(sql, aCustomer.db_id) {|row| result << load(row)}
load_line_items result
return result
end
def load row
result = Order.new(row['orderID'], row['date'])
return result
end
def load_line_items orders
#Cannot load with load(row) as connection gets busy
orders.each do
|anOrder| anOrder.line_items = LineItemMapper.new.find_for_order anOrder
end
end
end

class LineItemMapper
def find_for_order order
result = []
sql = "select * from lineItems where orderID = ?"
$dbh.select_all(sql, order.db_id) {|row| result << load(row)}
return result
end
def load row
return LineItem.new(row['lineNumber'], row['product'], row['cost'].to_i.dollars)
end
end

class Customer...
attr_accessor :name, :db_id, :orders
def initialize db_id, name
@db_id, @name = db_id, name
end

class Order...
attr_accessor :date, :db_id, :line_items
def initialize (id, date)
@db_id, @date, @line_items = id, date, []
end

class LineItem...
attr_reader :line_number, :product, :cost
def initialize line_number, product, cost
@line_number, @product, @cost = line_number, product, cost
end

class Customer...
def cuillenMonths
result = []
orders.each do |o|
result << o.date.month if o.cuillen?
end
return result.uniq
end

class Order...
def cuillen?
discountableAmount = 0.dollars
line_items.each do |line|
discountableAmount += line.cost if 'Talisker' == line.product
end
return discountableAmount > 5000.dollars
end

Вот так пишут нормальные программисты:
 
static IEnumerable<int> CuillenMonths(string companyName)
{
var customerID = Query.Create<int>(
"SELECT CustomerID FROM Customer WHERE CompanyName = @companyName",
new {companyName}).GetEnumerable.Single;
return Query.Create<T001>(
"SELECT OrderID, OrderDate FROM Order WHERE CustomerID = @customerID",
new {customerID}).GetEnumerable
.Where(IsCuillen)
.Select(order => order.OrderDate.Month)
.Distinct;
}

static bool IsCuillen(T001 order)
{
return Query.Create<T002>(
"SELECT ProductID, Quantity FROM OrderLine WHERE OrderID = @OrderID",
new {order.OrderID}).GetEnumerable
.Where(line => line.ProductID == 2702)
.Sum(line => line.Quantity) > 14;
}

6yrop

Вот так пишут нормальные программисты:
Вот так вносят изменения нормальные программисты:
 
static IEnumerable<int> CuillenMonths3(string companyName)
{
var customerID = Query.Create<int>(
"SELECT CustomerID FROM Customer WHERE CompanyName = @companyName",
new {companyName}).GetEnumerable.Single;
return Query.Create<T003>(@"
SELECT OrderLine.OrderID, OrderDate, ProductID, Quantity
FROM OrderLine JOIN Order ON OrderLine.OrderID = Order.OrderID
WHERE CustomerID = @customerID", new {customerID}).GetEnumerable
.GroupBy(_ => _.OrderID)
.Select(_ => new {
_.First.OrderDate,
Lines = _
})
.Where(order => IsCuillen(order.Lines
.Select(order => order.OrderDate.Month)
.Distinct;
}

static bool IsCuillen(IEnumerable<T003> lines)
{
return lines.Where(line => line.ProductID == 2702)
.Sum(line => line.Quantity) > 14;
}

Какой код после изменений получается у мега архитектора понять сложно. Функции add_order, add_line_item упоминаются, но не определены. Короче, если посмотреть diff-ы, то мега архитектор опять в пролете.

Ivan8209

> И застрелимся это понимать и тестировать.
А что ты тут собрался тестировать? JMS?
Если мне не изменяет память, то JMS это один из способов написания
распределённых программ, желание иметь это вполне понятно.
Если там сделано так, как ты пишешь, то оно уже локализовано в коде,
поэтому твои жалобы заключаются лишь в наличии модуля, занимающегося
распределением работы по разным виртуальным машинам.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."

psm-home

В мире явы принято
думать чуть дальше сегодняшнего дня, так как программу будут ещё
и запускать, а не положат пылиться в репозиторий.
Есть разные типы проектов. Вот товарищ работает в одном Лидере Розничного Кредитования. Да, половина здоровенного проекта на яве, вторая на PL/SQL (и третья на C# :grin: ). Процесс - самый настоящий водопад, прям наверное как ты любишь. Аккуратно собираются требования, неслабый штат аналитиков, тщательно продумывают, что и как все будет сделано в очередном релизе. Пишут BRD, FRD и много других страшных слов. Все у них по плану. В коде правда все равно встречается треш, угар и содомия, но это скорее по причине масштаба системы, без системного подхода все вообще бы развалилось, а так регулярно выкатывают новые фичи.
Есть другой тип проектов: всякие типа стартапы. Когда непонятно ни хрена точно, куда идем. Но идти надо. Чтобы понять, туда ли идем, нужно текущее видение представить в виде минимально работающего продукта. И чем быстрее, тем лучше. Потому что хуже нет в таком проекте, когда берут изначальное видение и начинаю строить прекрасный собор. Потом через полгодика выясняется, что уже заложен отличный фундамент, есть мощная инфраструктура, надо вот только теперь функциональность допилить. Ага, и допиливают, а потом когда показывают наконец заинтересованным лицам, оказывается, что надо было чего-то другое делать. Не собор оказывается надо было, а луна-парк. В таком проекте, как ни неприятно признать, выгоднее быть "перловщиком". Быстро строить работающие прототипы и безжалостно их править или даже просто выбрасывать. Чтобы что-то можно было безжалостно переделать под резко изменившиеся требования или даже выкинуть, надо чтоб оно было написано максимально просто, с минимум кода. Тогда хотя бы не так жалко усилий.
М. б подобная работа не совпадает с твоим представлением о достойной деятельности, м. б ты всегда хотел строить соборы, а не луна-парки из говна и палок. Но это не значит что таких проектов не бывает и они не нужны.

Ivan8209

Я вижу два куска кода, один из которых на чём-то питоноподобном,
но не питоне, другой --- на чём-то яваподобном, но не на яве.
Оба отрывка содержат разные запросы на SQL.
И что ты этим хотел показать?
---
"Университет развивает все способности, в том числе и глупость."

6yrop

И что ты этим хотел показать?
Куски кода делают одно и тоже! (Некоторые колонки отличаются названиями, просто под рукой была похожая база с заказами, я с ней и начал писать код).
Фаулер толкает мысль, что типа если мы заранее сделаем правильную систему классов, то при внесении изменения (он его описывает) нам не придется менять код-бизнес логики. Вот это всё туфта, ни какой выгоды от продумывания заранее нет. Только вред.

6yrop

Оба описанных типа проектов можно вести спокойно, нарабатывая постепенно функционал.

Ivan8209

> Есть другой тип проектов: всякие типа стартапы.
Если ты хочешь сказать, что ява не подходит для прототипирования,
то могу сказать только одно: ты просто не умеешь писать прототипы.
Писать прототипы тоже надо уметь, и здесь как раз ява, даже с её
примитивной типизацией, только помогает, и вопрос только в том,
что надо знать инструмент, которым пользуешься. В этом смысле
ява абсолютно превосходит питон во всём, кроме одного: больше
индусов учат писать на питоне. Это, правда, очень мало помогает,
так как борьба этапа написания переносится на этап тестирования,
а даже прототип должен уметь что-то делать.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."

psm-home

А что ты тут собрался тестировать? JMS?
Ну в сам JMS положим я верю, как верю в приличную РСУБД. Тестировать его наверное незачем. Хотя конечно в случае persistent режима отработает ли как надо конкретная реализация JMS провайдера падение процесса JMS - это вопрос открытый, можно и проверить.
Если мне не изменяет память, то JMS это один из способов написания
распределённых программ, желание иметь это вполне понятно.
Если там сделано так, как ты пишешь, то оно уже локализовано в коде,
поэтому твои жалобы заключаются лишь в наличии модуля, занимающегося
распределением работы по разным виртуальным машинам

Может быть я плохо объясняю. Там просто не нужен JMS. Потому что конкретно этот проект влезает на одну коробку по CPU/RAM и долго еще будет влезать. И да, автор ничего не предложил для разделения работы по нескольким VM, даже в перспективе. Т. е конкретно в этом случае получается, что вместо inprocess вызова мы ставим сообщение в JMS очередь (это разговор с JMS брокером по tcp, JMS брокер пишет на диск в журнал, делает fsync потом тут же, в том же самом процессе получаем это сообщение (это опять разговор по tcp, опять обращение к диску). Если так хотелось в этом сценарии асинхронности и теплых ламповых сообщений достаточно было иметь обычную очередь внутри процесса и разгребающий её пул ниток. Но даже это в большей части кода проекта лишнее, потому что асинхронность там реально нужна только в паре мест, для того чтобы не делать sleep и не занимать нить, когда по протоколу взаимодействия с другой системой нужно сделать retryAfter(10, SECONDS).

psm-home

Если ты хочешь сказать, что ява не подходит для прототипирования
Неа, не хочу. Неплохо она подходит, хочешь, можешь строить соборы, не хочешь, берешь минимальный набор инструментов и быстро запиливаешь прототип на выброс.
Хотел сказать только, что не всегда имеет смысл задел на будущее. Потому что будущее может оказаться совсем не таким, как ты его себе представлял. Это не всегда так, но это практически важный случай и глупо делать вид, что так не бывает.

luna89

мы имеем КакаяТоХерняService.method ->КакаяТоХерняServiceSender.sendJmsMessage (тут перепаковка параметров в сообщение)->JMS очередь->КакаяТоХерняListener (тут распаковка сообщения в параметры)->КакаяТоХерняService.method2.
А сендер и листенер в одной и той же JVM находятся?

psm-home

Да. По-моему это какой-то просто долбаный стыд.

luna89

И еще вопрос - лисенер делает что-либо типа рассылки почты или смс, или вызова веб-сервисов?

psm-home

90% лиснеров - нет. Я ж выше написал, что есть всего пара случаев, где мы общаемся там с внешней системой, протокол с повторами и там как раз имеет смысл сделать на сообщениях (не обязательно на JMS, чего-то вроде ScheduledExecutorService было бы достаточно).

psm-home

Да и ещё момент, который, как выяснилось, не все восторженные любители JMS осознают. Вообще говоря, когда в приложении кроме БД заводится еще и очередь, особенно со включенным persistent режимом, нужно заботится о координации появляющихся распределенных транзакций. Ну т. е как минимум включить/настроить это дело, а не делать вид, что оно как-то само, как было сделано в обсуждаемом проекте.

luna89

Да и ещё момент, который, как выяснилось, не все восторженные любители JMS осознают. Вообще говоря, когда в приложении кроме БД заводится еще и очередь, особенно со включенным persistent режимом, нужно заботится о координации появляющихся распределенных транзакций. Ну т. е как минимум включить/настроить это дело, а не делать вид, что оно как-то само, как было сделано в обсуждаемом проекте.
Если у тебя оракл, то наверное JMS брокер - AQ? Тогда распределенные транзакции не нужны.

psm-home

Если бы. :) Не видали у нас никаких AQ. Там совершенно постороннее изделие.

Dasar

так как
неатомарность "obj.method" воспринимается при чтении хуже,
чем раздельная отсылка и получение ответа
он не атомарен в многопоточном коде, но такой ситуации и не бывает, потому что это противоречит первому правилу многопоточного программирования: "Никогда не пишите многопоточный код" (c)

luna89

90% лиснеров - нет. Я ж выше написал, что есть всего пара случаев, где мы общаемся там с внешней системой, протокол с повторами и там как раз имеет смысл сделать на сообщениях (не обязательно на JMS, чего-то вроде ScheduledExecutorService было бы достаточно).
Хз тогда. Я бы отталкивался от того, что сообщение не доставляется, пока транзакция не комитится, то есть юзер гарантированно не получит СМС о списании бабла, если произойдет сбой и бабло не спишется.

psm-home

Да, случай с СМСками это ок, подходящий пример, когда JMS на своем месте, тут я и не спорю особо. А когда у тебя внутри процесса вызов заменяется на посылку JMS сообщения, при этом никакого взаимодействия с внешним миром нет, это я считаю уже перебор. А вообще про необходимость 2PC в реальной жизни помнится была забавная статейка: Your Coffee Shop Doesn’t
Use Two-Phase Commit
.

psm-home

то есть юзер гарантированно не получит СМС о списании бабла, если произойдет сбой и бабло не спишется
Это достигается совсем просто же. Ты можешь слать СМС после COMMIT, разве нет?
API СМС шлюза часто представляет собой единственный HTTP вызов, в котором передается номер адресата, строка, которая будет подставлена в номер отправителя и текст сообщения. Никаких транзакций в API такого шлюза нет. При таком раскладе, как ни упирайся, ты не избежишь того например, что иногда СМС будет доставлена больше одного раза.

vmo49

мехмат — гавно!111

6yrop

но ВМиК не лучше

vmo49

физфак тоже не фонтан :D
а по сабжу — надо же на человека, а не на факультет смотреть

Serab

Когда продумывается продукт, уже обычно ясно, что, где и как
можно будет расширять. Это всякие питонщики и перловщики готовы
переписывать всё постоянно, как только чуть-чуть требования
поменяются.
тут ты тоже теоретизируешь, препроектировние тоже бывает и зачастую ведет к серьезным проблемам (например, когда не угадали, в какую сторону гибкость потребуется). Поэтому умение остановиться на определенном уровне гибкости и при необходимости рефакторить необходимо. А еще это гарантированно занимает времени, причем не факт, что меньше, чем зарефакторить потом. И все-таки иногда новые требования действительно появляются позже.
Оставить комментарий
Имя или ник:
Комментарий: