прогеры: ММ или ВМиК?
Слишком толсто.
вмк - это уже скорее архитектор или старший шаман, обеспечивающий работу сложной инфраструктурной системы.
мехмат - бизнес-аналитик или мат. обеспечение сложных алгоритмов.
Я ВМК, сзм, на работу не брать.
мехмат - бизнес-алкоголик
вмк - это уже скорее архитектор или старший шаманХороший архитектор — строго не шаман, но это моё мнение. Вообще, шаманство я считаю наебкой работодателя. Либо ты делаешь на совесть, как можешь, либо постоянно что-то костылями правишь и шаманишь, и без тебя хз что будет.
А вот шаманство как раз вмк-шный признак. Мехмат более склонен выяснить все детали и сделать очень ответственно, вникнув во все мелочи.
В то же время вмк-шник может по-быстрому набрать кучу говна и заставить хоть как-то работать. Мехмат скорее пошлёт с этой кучей говна куда подальше.
по-быстрому набрать кучу говна и заставить хоть как-то работатьВ моей выборке мехмат за таким занятием был замечен в равной степени. Дело не в факультете.
Интересно процентное соотношение и репрезентативность выборок.
И гипотезу нормально сформулируйте!
да что там вмк, вон пианист даже форум не смог собрать
прогеры: ММ или ВМиК?ХимФак.
Заминусовали, демоны!
Мне физики нравятся в этом плане.
главное не брать пианистов
Какой процент совсем в сторону сзм?
Это ты намекаешь, что у тебя в конторе карты написаны так, что ими пользуются только из-за того, что тот, кто писал, хорошо знал местность, а о usability и дизайне не подумал, поэтому получилось квадратно-гнездовым, по сравнению с конкурентами? Тебе морду надо начистить на петровско-разумовской, чтобы ты поменьше троллил.
У мм профиль шире, но дегенератов вроде тебя и там хватает. Я бы тебя не взял. Из-за упоротости.
ого, нифига себе что бывает, если человек забывает принять прописанное доктором препаратики...
но не изза того что там лучше учат. А просто на мехмате больше людей с завышенным чсв, что они мега ученные.
Чтоб стать норм программистом надо чтобы тебе ставили сложные задачи, без подсказок как ее осуществлять и реалистичным сроком.
Те если бы учили так:
"Вот тебе задача на неделю, я сам не знаю как делать ее , читай, делай, срок неделя"
То из таких людей ковались бы мега программисты.
Не на мехмате и вмк так не делают.
Имхо главное в программисте не знание, а способность находить и решать задачу.
"Вот тебе задача на неделю, я сам не знаю как делать ее , читай, делай, срок неделя"мега хуисты из таких людей получаются. процент людей, которые в собственном вакууме решат задачу правильно, а не с помощью уже имеющихся знаний, даже если они не применимы или устарели, очень мал
То из таких людей ковались бы мега программисты.
Имхо главное в программисте не знание, а способность находить и решать задачу.Вброс: на мехмате _НЕ_ дают вообще знаний в том смысле, как это делают на ВМиК и тем более в других вузах. Максимум чему учат — каким-то азам, и то, скорее просто дают методичку и направление куда копать. Стандартный мехматянин, вообще говоря, — это просто прокаченный мозг, который на порядок меньше знает выпускника кулинарного, но именно этот мозг может весь курс кулинарного заботать быстренько.
На ВМиК же существенно меньше идёт тренировки мозга, и гораздо больше дается знаний. Хорошо, если это — знания «академического типа», чаще же всего прошивают прямо в мозг конкретные технологии. Весьма распространён вариант, когда впариваются технологии устаревшие или откровенно хреновые, но нравящиеся конкретному преподу. Вместе с этим сеют наборы стереотипов и просто дурновкусие, после которого вроде как свеженький вьюноша уже перестаёт воспринимать что-то другое.
Может ли у чела с ММ быть привито дурное? Да, запросто, но это уже прививается или на первой работе, или от товарищей. Сами факультетские курсы вообще ничего не "продают", по сути являясь максимально абстрагированными от любой идеологии.
В то же время, стоит отметить, что стандартные на 1-2 курсе прогерские предметы на ВМиК — очень хорошие. Я о курсе алгоритмов с Паскалем, ассермблере и системном прогании. Но, к сожалению, посеянное доброе-вечное затем зарастает сорняками. Как итоге — вмк-шник запросто завалит вопросы типа "какая сложность у такого-то запроса" по своей любимой БД, но зато бодро будет вещать про абстрактный маппинг объектов в его любимом ORM.
от моих знакомых кто учился там я знаю, что там такоеже впихивание теорем как и везде
и развивающими задачами и не пахнет
как к примеру в ЗФТШ (кто учился)
там такоеже впихивание теорем как и вездеМатематику правильно впихивают, собственно об этом факультет, чем ты не доволен?
познавательные и развивающие задачи — это этап мат. школы, и олимпиад. На мехмат уже приходят с этим багажом.
познавательные и развивающие задачи — это этап мат. школы, и олимпиада должна быть вся жизнь
Математику правильно впихивают, собственно об этом факультет, чем ты не доволен?ну математику впихивают на мехмате , вмк, физфаке
почему ты считаешь что именно на мехмате ее впихивают правильно
Я о курсе алгоритмов с Паскалем, ассермблере и системном прогании.Алгоритмы с Паскалем был вообще единственным курсом, который я не считаю потраченным временем. Реально крутой курс. К сожалению, дальше курсы были какие-то бестолковые. Я бы на второй семестр поставил какой-нибудь питон, чтобы студенты были в состоянии хоть что-то запрогать (а то получается, что отучившись год, студенты способны кодить только в турбопаскале). Тогда бы и C в третьем семестре хорошо бы пошел. C++ в четвертом надо вообще выбросить.
почему ты считаешь что именно на мехмате ее впихивают правильноа где я такое утверждал? речи про математику не было.
топик о том, откуда какие прогеры, у кого какие мнения.
Стандартный мехматянин, вообще говоря, — это просто прокаченный мозг,"Мехматянин — прокаченный мозг" это у вас там местная байка (шаблон) на факультете такая? Просто я ее несколько раз уже слышал от разных мехматян. Не мог бы ты развернуть понятие "прокаченный мозг"? Это быстро заботать курс кулинарного? Т.е. прокаченный мозг это способность быстро воспринимать шаблоны и жонглировать ими?
Прокачанный мозг - это хорошая память.
Прокачанный мозг - это хорошая память.Дейкстра говорит, что лучше научиться жить с маленьким размером человеческой головы:
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
Кстати, у филологов тоже неплохая память.
(а то получается, что отучившись год, студенты способны кодить только в турбопаскале)Умея кодить в турбопаскале, можно успешно кодить в дельфях и фрипаскале. А это уже что-то.
Умея кодить в турбопаскале, можно успешно кодить в дельфях и фрипаскале. А это уже что-то.Проблема в библиотеках.
Главная отличительная черта хорошего программиста это способность к построению хороших абстракцийКто как не математики имеют способность к построению абстракций и оперированию символьными данными.
Кто как не математики имеют способность к построению абстракций и оперированию символьными данными.Далеко не все могут вырабатывать хорошие абстракции. Ты не путай выработку абстракций и работу с абстракциями. Все математики работают с абстракциями, но не факт, что все могут их производить.
Далеко не все могут вырабатывать хорошие абстракции.И при этом каждый второй — гениальнейший проектировщик структуры классов!
Каждый третий — проектировщик структуры БД!
И лишь каждый сотый включает мозг и задает вопросы, касающиеся производительности, потребления ресурсов, времени отклика. И он-то меньше всего лезет с темой гениальной структуры классов и ORM!
Далеко не все могут вырабатывать хорошие абстракции.Верно, но математики как раз и есть те, кто производит математическое знание, а именно создают новые истинные абстрактные выражения.
Ты не путай выработку абстракций и работу с абстракциями. Все математики работают с абстракциями, но не факт, что все могут их производить.Нет, это инженеры делают приложения готового знания, а учёные знание производят, в частности математики производят новые абстрактные конструкции и упрощают существующие.
Если для тебя математик — это человек, окончивший мехмат, то рекомендовал бы тебе всё же придерживаться стандартной терминологии.
И лишь каждый сотый ... задает вопросы, касающиеся производительности, потребления ресурсов, времени отклика.Тут говорят, наоборот, многие заморочены на это:
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%?
Фигня в том, что надо не что-то одно делать, а сразу в комплексе задачи решать. А упоротые любители синтаксического сахара никогда не смотрят на то, что программу в итоге будет выполнять ЭВМ.
Никто не мешает писать понятно для человека, и думать в этом направлении. Не надо только в жертву приносить всё остальное.
А упоротые любители синтаксического сахара никогда не смотрят на то, что программу в итоге будет выполнять ЭВМ.а вот авторы SICP говорят, что программы созданы для чтения людьми, а не машинами
Ну и в итоге получаем тормозное Руби.Ты сам на чем и что пишешь?
программы созданы для чтения людьми, а не машинамиПрограммы созданы для выполнения машинами, но должны быть понятны людям.
Кстати, гениальные штуки как раз очень гармонично сочетают в себе всё. А бездарности рождают всякие Явы, которые обжираются ресурсами, и по сути принесли в индустрию извращенно длинный стиль писанины. Ибыточный настолько, что без вспомогательных средств в виде кодогенераторов и комплишенов не получится даже писать программы, просто набивать код задолбаешься.
Ты сам на чем и что пишешь?На разном, могу оценку так дать:
1. Питон — удобно писать, код прозрачный, выполняется предсказуемо на троечку, но язык высокого уровня. Разумеется, джанго — невероятная срань, использовать которую нельзя, но есть в питоне куча хороших библиотек.
2. ПХП — хорошая производительность, жутко сложно писать прозрачный код, сам язык провоцирует на говнокодинг. В целом, для веба остается лучшим языком, кто бы что ни говорил.
3. Чистый Си. Пишу библиотеки всякие, которые использую из плюсов. По сути — это современный ассемблер, но писать на нём легко и приятно, если знать как.
4. Плюсы — всем хорош, но для разработки веб-интерфейсов не использую.
5. mysql — хорошая база данных, но только пока видишь её снаружи. В сам код лучше не залезать. Предсказуемая, известно почти всё, что надо для стабильной работы.
6. mongodb — прекрасная штука, но есть претензии к используемому дисковому пространству. Есть подозрение, что писали очень неэффективно внутри, но что делать — это лучшее, что есть с автоматическим шардингом.
7. javascript в браузре. Мне нравится этот язык, нравится библиотека jquery. Всё достаточно удобно и работает относительно шустро.
Куски говна:
1. Ява
2. Хадуп
3. Флэш
4. Сишарп
5. Сильверлайт
6. Эрланг — это вообще порождение воспалённого сознания
7. визуал бейсик
Эрланг — это вообще порождение воспалённого сознанияа кстати почему? вот питон, сишечка и похапе ок, а эрланг не угодил. синтаксис стремный и строки через жопу, а что ещё?
> А бездарности рождают всякие Явы, которые обжираются ресурсами,
> и по сути принесли в индустрию извращенно длинный стиль писанины.
Не надо тут "ля-ля", ява офигенно хорошо спроектированный язык,
в отличие от всяких тормозных и убогих питонов и пыхпыхов.
А стиль диктуется задачами. Если бы в питоне можно было
заставить индусов писать более корректный код, для разбора
которого не требуется смотреть всю программу целиком,
то и там пришлось бы писать длинно.
---
"Люди недалёкие обычно осуждают всё, что выходит за пределы их понимания."
"Only ugly languages become popular. Python is the one exception" — Donald Knuth
эрланг не угодил. синтаксис стремный и строки через жопу, а что ещё?синтаксис пофиг.
функциональный он, а процессор ориентирован на процедурность. конечно, как машины Тьюринга они эквивалентны, но вот стоимость этой эквиваленции как раз очень высокая.
Поэтому всё на Эрланге будет работать заведомо хуже, чем на других языках, которые больше к архитектуре приспособлены.
ява офигенно хорошо спроектированный язык, в отличие от всяких тормозных и убогих питонов и пыхпыховПыха быстрый как понос, и вообще пыха — только для веба.
А вот на Яве веб пишут только совсем ублюдки. Достаточно посмотреть Джиру — образец тормоза. Тот же трак на Питоне просто летает в сравнении с Джирой.
> Поэтому всё на Эрланге будет работать заведомо хуже,
> чем на других языках, которые больше к архитектуре приспособлены.
После таких заявлений с тобой вообще бессмысленно разговаривать на эти темы.
---
"Люди недалёкие обычно осуждают всё, что выходит за пределы их понимания."
А вот на Яве веб пишут только совсем ублюдки.Ява просто традиционно ЯП для энтерпрайза, там веб делают по остаточному принципу обычно. Типа, чо, фронтенд-разработчик? Это кто такой, не, не слышал. А так особой проблемы нет, точно также как в пыхе можно взять простейший шаблонизатор (freemarker какой-нибудь взять голимое JDBC для доступа к БД, легкий http сервер, типа jetty. И будет не хуже, чем на PHP. Сама по себе JVM штука вылизанная и быстрая. Да, память оно конечно ест, но она сейчас дешевая. Просто так обычно на яве не пишут, не та культура, но тут дело не столько в языке, сколько в людях.
Просто так обычно на яве не пишут, не та культура, но тут дело не столько в языке, сколько в людях.Культура вообще у явы особая, это раковая опухоль.
раковая опухольНу есть немного, сейчас вот сижу и удаляю-удаляю-удаляю из проекта классы. Оверинжениринг в полный рост, плюс много-много особой уличной магии. Мантра про явное, которое лучше, чем неявное тут не в почете. Это все зависит от точки зрения ещё, кто-то из коллег скажет, что я мудак, там мол был задел на будущее развитие и гибкость, а я всю красоту похерил и налепил ad hoc-ов.
кто-то из коллег скажет, что я мудак, там мол был задел на будущее развитиеНу да, пишут решение задачи, которую ещё не придумали.
А ты уверен, что там действительно не было задела на развитие?
В отличие от питона, где принято лепить код, как на перле,
в яве как раз принята дисциплина программирования. Ты вот сейчас
поудаляешь, потом придёт какой-нибудь индус и вместо того,
чтобы вставить части из удалённого, напишет какой-нибудь бред,
который потом придётся переделывать долго и мучительно.
---
"Narrowness of experience leads to narrowness of imagination."
ты уверен, что там действительно не было задела на развитие?Конкретно в этом случае я уверен. Иначе не махал бы шашкой. А вообще это интересный вопрос, как научиться надежно отличать одно от другого. Хотел бы я так уметь.
Собственно я режу-то почему, потому что код написан очень сложно без причины. Там все такое асинхронное, ни слова в простоте, JMS очереди повсюду, прекрасные FSM на мешанине из if-ов и try/catch, 3 слоя абстракции над БД, одновременно pessimistic и optimistic locks и это ничем не мотивировано. Ну вот буквально: "почему собака лижет яйца - потому что может". А я считаю что простые вещи должны делаться просто, для сложности должна быть причина, для лишних строк кода должен быть мотив. Нет его, не можешь объяснить, какие выгоды сулит посылка сообщения, вместо простого obj.method ну и значит я выкидываю все эти умствования.
> вместо простого obj.method ну и значит я выкидываю все эти умствования.
Вот это вообще бред. Доказывать надо как раз противоположное:
что посылку сообщения и ожидание ответа можно заменить,
так как "obj.method" это грязный хак для оптимизации.
Он, в частности, прячет проблемы синхронизации, так как
неатомарность "obj.method" воспринимается при чтении хуже,
чем раздельная отсылка и получение ответа. А когда проблемы
обнаружатся, придётся делать ещё один тип, который будет
превращать этот хак в правильную посылку. В итоге
вместо правильного употребления общего механизма
будет употреблён он же, но с промежуточным шагом.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
задела на развитие?ReSharper всё сделает когда придет время
Ты вот сейчас
поудаляешь, потом придёт какой-нибудь индус и вместо того,
чтобы вставить части из удалённого, напишет какой-нибудь бред,
который потом придётся переделывать долго и мучительно.
от таких всё равно не застрахуешься, все же куски заранее не напишешь
Да-да, какой-то инструмент, который преобразовывает код
неустановленным образом, магически приведёт код в соответствие
с первоначальным замыслом.
> от таких всё равно не застрахуешься, все же куски заранее не напишешь
Когда продумывается продукт, уже обычно ясно, что, где и как
можно будет расширять. Это всякие питонщики и перловщики готовы
переписывать всё постоянно, как только чуть-чуть требования
поменяются.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
Когда продумывается продукт, уже обычно ясно, что, где и како расширении даже думать не надо, пустая трата усилий и времени. Реализовывай текущие требования.
можно будет расширять.
Это всякие питонщики и перловщики готовы
переписывать всё постоянно, как только чуть-чуть требования
поменяются.
Конечно, они даже вызовы метода не могут найти, как тут недавно писали.
> Реализовывай текущие требования.
Да-да, "урвать и убежать," "после нас хоть потоп" --- узнаю перловщиков.
"Текущие требования" составлены, как правило, с учётом того, что потом,
на следующем этапе придётся реализовывать настоящие "текущие требования,"
а не то, насчёт чего договорились на текущий этап. В мире явы принято
думать чуть дальше сегодняшнего дня, так как программу будут ещё
и запускать, а не положат пылиться в репозиторий.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
method {
ojb.method2;
}
мы имеем КакаяТоХерняService.method ->КакаяТоХерняServiceSender.sendJmsMessage (тут перепаковка параметров в сообщение)->JMS очередь->КакаяТоХерняListener (тут распаковка сообщения в параметры)->КакаяТоХерняService.method2.
Это не Erlang и не scala actors. Это намного, намного многословнее. И главное, в этом нет смысла (конкретно в моем случае). Не, ну давайте на всем пути выполнения заменим линейный вызов метода на посылку сообщений в таком стиле. И застрелимся это понимать и тестировать.
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;
}
Вот так пишут нормальные программисты:Вот так вносят изменения нормальные программисты:
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-ы, то мега архитектор опять в пролете.
А что ты тут собрался тестировать? JMS?
Если мне не изменяет память, то JMS это один из способов написания
распределённых программ, желание иметь это вполне понятно.
Если там сделано так, как ты пишешь, то оно уже локализовано в коде,
поэтому твои жалобы заключаются лишь в наличии модуля, занимающегося
распределением работы по разным виртуальным машинам.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
В мире явы принятоЕсть разные типы проектов. Вот товарищ работает в одном Лидере Розничного Кредитования. Да, половина здоровенного проекта на яве, вторая на PL/SQL (и третья на C# ). Процесс - самый настоящий водопад, прям наверное как ты любишь. Аккуратно собираются требования, неслабый штат аналитиков, тщательно продумывают, что и как все будет сделано в очередном релизе. Пишут BRD, FRD и много других страшных слов. Все у них по плану. В коде правда все равно встречается треш, угар и содомия, но это скорее по причине масштаба системы, без системного подхода все вообще бы развалилось, а так регулярно выкатывают новые фичи.
думать чуть дальше сегодняшнего дня, так как программу будут ещё
и запускать, а не положат пылиться в репозиторий.
Есть другой тип проектов: всякие типа стартапы. Когда непонятно ни хрена точно, куда идем. Но идти надо. Чтобы понять, туда ли идем, нужно текущее видение представить в виде минимально работающего продукта. И чем быстрее, тем лучше. Потому что хуже нет в таком проекте, когда берут изначальное видение и начинаю строить прекрасный собор. Потом через полгодика выясняется, что уже заложен отличный фундамент, есть мощная инфраструктура, надо вот только теперь функциональность допилить. Ага, и допиливают, а потом когда показывают наконец заинтересованным лицам, оказывается, что надо было чего-то другое делать. Не собор оказывается надо было, а луна-парк. В таком проекте, как ни неприятно признать, выгоднее быть "перловщиком". Быстро строить работающие прототипы и безжалостно их править или даже просто выбрасывать. Чтобы что-то можно было безжалостно переделать под резко изменившиеся требования или даже выкинуть, надо чтоб оно было написано максимально просто, с минимум кода. Тогда хотя бы не так жалко усилий.
М. б подобная работа не совпадает с твоим представлением о достойной деятельности, м. б ты всегда хотел строить соборы, а не луна-парки из говна и палок. Но это не значит что таких проектов не бывает и они не нужны.
но не питоне, другой --- на чём-то яваподобном, но не на яве.
Оба отрывка содержат разные запросы на SQL.
И что ты этим хотел показать?
---
"Университет развивает все способности, в том числе и глупость."
И что ты этим хотел показать?Куски кода делают одно и тоже! (Некоторые колонки отличаются названиями, просто под рукой была похожая база с заказами, я с ней и начал писать код).
Фаулер толкает мысль, что типа если мы заранее сделаем правильную систему классов, то при внесении изменения (он его описывает) нам не придется менять код-бизнес логики. Вот это всё туфта, ни какой выгоды от продумывания заранее нет. Только вред.
Оба описанных типа проектов можно вести спокойно, нарабатывая постепенно функционал.
Если ты хочешь сказать, что ява не подходит для прототипирования,
то могу сказать только одно: ты просто не умеешь писать прототипы.
Писать прототипы тоже надо уметь, и здесь как раз ява, даже с её
примитивной типизацией, только помогает, и вопрос только в том,
что надо знать инструмент, которым пользуешься. В этом смысле
ява абсолютно превосходит питон во всём, кроме одного: больше
индусов учат писать на питоне. Это, правда, очень мало помогает,
так как борьба этапа написания переносится на этап тестирования,
а даже прототип должен уметь что-то делать.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
А что ты тут собрался тестировать? JMS?Ну в сам JMS положим я верю, как верю в приличную РСУБД. Тестировать его наверное незачем. Хотя конечно в случае persistent режима отработает ли как надо конкретная реализация JMS провайдера падение процесса JMS - это вопрос открытый, можно и проверить.
Если мне не изменяет память, то JMS это один из способов написания
распределённых программ, желание иметь это вполне понятно.
Если там сделано так, как ты пишешь, то оно уже локализовано в коде,
поэтому твои жалобы заключаются лишь в наличии модуля, занимающегося
распределением работы по разным виртуальным машинам
Может быть я плохо объясняю. Там просто не нужен JMS. Потому что конкретно этот проект влезает на одну коробку по CPU/RAM и долго еще будет влезать. И да, автор ничего не предложил для разделения работы по нескольким VM, даже в перспективе. Т. е конкретно в этом случае получается, что вместо inprocess вызова мы ставим сообщение в JMS очередь (это разговор с JMS брокером по tcp, JMS брокер пишет на диск в журнал, делает fsync потом тут же, в том же самом процессе получаем это сообщение (это опять разговор по tcp, опять обращение к диску). Если так хотелось в этом сценарии асинхронности и теплых ламповых сообщений достаточно было иметь обычную очередь внутри процесса и разгребающий её пул ниток. Но даже это в большей части кода проекта лишнее, потому что асинхронность там реально нужна только в паре мест, для того чтобы не делать sleep и не занимать нить, когда по протоколу взаимодействия с другой системой нужно сделать retryAfter(10, SECONDS).
Если ты хочешь сказать, что ява не подходит для прототипированияНеа, не хочу. Неплохо она подходит, хочешь, можешь строить соборы, не хочешь, берешь минимальный набор инструментов и быстро запиливаешь прототип на выброс.
Хотел сказать только, что не всегда имеет смысл задел на будущее. Потому что будущее может оказаться совсем не таким, как ты его себе представлял. Это не всегда так, но это практически важный случай и глупо делать вид, что так не бывает.
мы имеем КакаяТоХерняService.method ->КакаяТоХерняServiceSender.sendJmsMessage (тут перепаковка параметров в сообщение)->JMS очередь->КакаяТоХерняListener (тут распаковка сообщения в параметры)->КакаяТоХерняService.method2.А сендер и листенер в одной и той же JVM находятся?
Да. По-моему это какой-то просто долбаный стыд.
И еще вопрос - лисенер делает что-либо типа рассылки почты или смс, или вызова веб-сервисов?
90% лиснеров - нет. Я ж выше написал, что есть всего пара случаев, где мы общаемся там с внешней системой, протокол с повторами и там как раз имеет смысл сделать на сообщениях (не обязательно на JMS, чего-то вроде ScheduledExecutorService было бы достаточно).
Да и ещё момент, который, как выяснилось, не все восторженные любители JMS осознают. Вообще говоря, когда в приложении кроме БД заводится еще и очередь, особенно со включенным persistent режимом, нужно заботится о координации появляющихся распределенных транзакций. Ну т. е как минимум включить/настроить это дело, а не делать вид, что оно как-то само, как было сделано в обсуждаемом проекте.
Да и ещё момент, который, как выяснилось, не все восторженные любители JMS осознают. Вообще говоря, когда в приложении кроме БД заводится еще и очередь, особенно со включенным persistent режимом, нужно заботится о координации появляющихся распределенных транзакций. Ну т. е как минимум включить/настроить это дело, а не делать вид, что оно как-то само, как было сделано в обсуждаемом проекте.Если у тебя оракл, то наверное JMS брокер - AQ? Тогда распределенные транзакции не нужны.
Если бы. Не видали у нас никаких AQ. Там совершенно постороннее изделие.
так какон не атомарен в многопоточном коде, но такой ситуации и не бывает, потому что это противоречит первому правилу многопоточного программирования: "Никогда не пишите многопоточный код" (c)
неатомарность "obj.method" воспринимается при чтении хуже,
чем раздельная отсылка и получение ответа
90% лиснеров - нет. Я ж выше написал, что есть всего пара случаев, где мы общаемся там с внешней системой, протокол с повторами и там как раз имеет смысл сделать на сообщениях (не обязательно на JMS, чего-то вроде ScheduledExecutorService было бы достаточно).Хз тогда. Я бы отталкивался от того, что сообщение не доставляется, пока транзакция не комитится, то есть юзер гарантированно не получит СМС о списании бабла, если произойдет сбой и бабло не спишется.
то есть юзер гарантированно не получит СМС о списании бабла, если произойдет сбой и бабло не спишетсяЭто достигается совсем просто же. Ты можешь слать СМС после COMMIT, разве нет?
API СМС шлюза часто представляет собой единственный HTTP вызов, в котором передается номер адресата, строка, которая будет подставлена в номер отправителя и текст сообщения. Никаких транзакций в API такого шлюза нет. При таком раскладе, как ни упирайся, ты не избежишь того например, что иногда СМС будет доставлена больше одного раза.
мехмат — гавно!111
но ВМиК не лучше
а по сабжу — надо же на человека, а не на факультет смотреть
Когда продумывается продукт, уже обычно ясно, что, где и кактут ты тоже теоретизируешь, препроектировние тоже бывает и зачастую ведет к серьезным проблемам (например, когда не угадали, в какую сторону гибкость потребуется). Поэтому умение остановиться на определенном уровне гибкости и при необходимости рефакторить необходимо. А еще это гарантированно занимает времени, причем не факт, что меньше, чем зарефакторить потом. И все-таки иногда новые требования действительно появляются позже.
можно будет расширять. Это всякие питонщики и перловщики готовы
переписывать всё постоянно, как только чуть-чуть требования
поменяются.
Оставить комментарий
Werdna
Холиварный топик, кто? Какой процент хороших? Какой процент совсем в сторону сзм? Кого бы предпочли взять на работу, мм или вмк?