Я поважаю opensource взагалі і навіть маю бажання продовжувати його традиції, коли буде час. Та я намагаюсь не використовувати чужі розробки. Саме тому зараз ми ведемо роботу над своїм фреймворком. Він буде слабеньким за аналоги. Слабеньким поки що. Адже від версії до версії хлопці матимуть більше досвіду і зможуть робити більш серьйозні речі.
Чим відрізняється розробник фреймворку від його користувача? Розробник знає як воно працює. Він може відновити архітектуру, вдосконалити, оптимізувати у найкоротший час. Що треба, щоб отримати таку можливість, використовуючи "чужий" продукт? Маю 2 варіанти. 1 — колупатися у коді самостійно, вивчати правила роботи, експерементувати. 2 — почекати поки потрібний функціонал буде введено розробником або кимось зі спільноти.
Обидва варіанти — ризик та час. Дивлячись з політики бізнеса, коли функціонал потрібен зараз, другий варіант йде курити. Тож залишається тільки перше. А що таке передивитись готовий продукт і зрозуміти як він працює? Перщі думки, яки приходять — вдосконалення та переробки. І це я вважаю першим слабким місцем opensource. Як розробник, я хотів би напервно домогти хлопцям. Як бізнесмену мені потрібен продукт, кращий за аналоги. Як людина, що довгий час спостерігає за тенденціями і ринком, я напевно залишив би будь-які ідеї, бо досить багато було прикладів гинучих проектів (нажаль тут фактами я не підібью).
Тепер безпека. Як компанія, що надає послуги я беру на себе відповідальність за продукт. Ставити будь-що "чуже" великий ризик. Чому? — Процес підтримки забирає багато ресурсів. Плюс ризик отримати непрацюючу систему після встановлення нової заплатки.
Opensource для маленького та якісного бізнесу це досить дорого та ризиковано (можливо можна залишити тільки "якісного"). Тож краще робити свої продукти, навіть слабщі за функціоналом. Планувати розвиток самостійно. Надавати рішення, шо працюють та допомогають клієнтам. І завжди знати, що коли буде прокол, то ти в мить владнаєш питання, адже знаєш кожен байт свого коду.
by JAM
Loading ...
декабря 1, 2007 в 3:32 pm
Предлагаю начать с операционной системы.
декабря 1, 2007 в 4:18 pm
Зачем? Оно платформонезависимое
В принципе суть написаного, как я понял: лучче писать своё и не парить мосх.
В принципе да - идеальный выход. И дело не в слабости-сильности. Продукт делаеццо под себя. Проектируя его ты проектируешь его именно под себя. В случае нестандартной задачи даж ядро переписать никто не повредит.
Сам раньше метался... CMS, фреймворки, руки... в итоге забил... начал писать. Базыи системы готов уже на 40% ... осталась админка и управлялка блоками... а дальше идёт модуля. Сруктура модулей чемто напоминает модули в друпале, с единой разницей - в друпале либы надо подключать вручную, у меня же всё на автомате. Всунул фичу аналогичную мамботам в джумле - вообще песня: хочешь cnstats прикрутить? пишешь бота в 3 строчки, ложишь в папку и при каждом запуске оно стартует. Ща админку пишу. Интересно то, что подобная система позволяет делать модуль в модуле, тоесть я пишу главную систему, в ней - модуль, а в модуле теми же операциями что в главной вызываю его модули и так досколькивлезет. Чувствую если закончу до следующего митапа - будет чего показать народу.
декабря 1, 2007 в 10:34 pm
Не конечно я понимаю настоящие мужики пишут только свое, это без вопросов.
А может ткнете пальцем во фреймворк-продукт?
Spring?
Struts?
Rails?
Symfony?
Django?
.NET?
Еще приводим бесконечный список на все случаи жизни .....
Они что за деньги продаются?За деньги непосредственного разве что МС Студия....
Написание гугла вроде как тоже не задача для малого бизнеса.
Продукт лучший за аналоги - да ок, все верно. Правда продукт, а не каркас на котором он построен.И уж точно делать свое нужно не из мотивации - "ниасилил другое"
декабря 1, 2007 в 10:53 pm
Фриц, подписываюсь под всем вышесказанным
декабря 1, 2007 в 11:06 pm
тут есть один момент в котором опенсорсовые хрени сосут перед самопалом. Момент заключаеццо в том, что в самопале ты подстраиваешь систему под свой стиль, а в опене - свой стиль под систему. Итог? Ну а где ты быстрее что-то напишешь - во фри фреймкорке, или в аналогичном но своём? Ясно что в своём. То может есть смысл потратить 1-2 месяца на ядро и навсегда забыть прочужое?
декабря 1, 2007 в 11:15 pm
Крайне спорное утверждение.
1. За 2 месяца не будет написано ничего особо хорошее. Комьюнити развивают фреймворки по много лет как правило при поддержке бизнеса.
2. Фреймворки как правило реализуют общие признаные принципы построения софта, это справедливо для всего кроме ну уж очень специфичных задач.
Веб-програминг - рядом не стоял с этими задачами.
3. Паттерны потому и называются паттерны.
декабря 1, 2007 в 11:20 pm
Статья про сабж:
http://ko.itc.ua/node/33048
декабря 2, 2007 в 12:51 am
2 Fritz --- ппкс
Товарищам, что рдеют алым стягом за "самописанный каркас" посвящается.
Все зависит от масштаба технологии порождаемым задачами, которые она призвана решать. При малых затратах времени создать клон существующих технологий компилятивным методом не привнеся ничегошеньки своего, нового, достаточно реально, но, зачастую, не оправданно и вот почему.
Как правило, компилятивные каркасы собранные из лоскутов чужих идей писались, пишутся и будут писаться студентами-разработчиками, которые начали осваивать технологию на этапе ее становления. При этом свои "наработки" объединяли в библиотеки, а поскольку задачи решались типовые, начали накапливаться шаблоны решений в итоге превратившиеся в каркас. Одна только беда, шаблоны решений были заимствованы из других продуктов, каркасов и проч софта, который на то время казался студенту "ппц громоздким", "на оно такое тяжелое", "мне надо только 5% из этого монстра" и проч. Прошло какое-то время, у студента накопился опыт решений только в рамках своего каркаса. Такому человеку просто жалко расставаться со свом творением как бы оно не выполняло свою задачу в сравнении с другими решениями. Это можно понять, но не поощрять вливаниями ресурсов со стороны инвесторов.
Все написанное выше не касается специализированных каркасов, которые уникальны в силу своей специализации и безусловно имеют право на ЖЦ
Ну и думаю никто не будете спорить, что клон технологической платформы вроде JEE и .NET самому писать бессмысленно (и даже с друзьями
). А это тоже каркасы.
декабря 2, 2007 в 6:26 am
Fritz, а теперь зайдём с другой стороны:
а кто мешает набрать комюнити на основе своего велосипеда? Зачем обязательно пристраиваццо к комуто в хвост? Собери велосипед, если он окажеццо жизнеспособным - его поддержут люди
декабря 2, 2007 в 11:14 am
GeX, не пристраивайся в хвост, пристраивайся в голову
Жизнеспособным, с точки зрения бизнеса, "велосипед" быть не может, поскольку, в отличии от давно стабильных каркасов, "велосипед" требует вложения значительных ресурсов.
декабря 2, 2007 в 1:28 pm
ну тут смотря в какой технологии ты сидишь
... в моём случае еще как может быть, мало того - должен быть, ибо то что рассматривал до этого ну до того кострубатое, что это ужас.
З.Ы.: а по поводу движков... ты эклипс переделывать не пробовал? или лучче туда не соваццо? бо с него собирают вплодь до 1С и офисного софта, следовательно каркас более чем гибкий...
декабря 2, 2007 в 1:32 pm
Гекс а за слова "кострубатое, что это ужас" ответишь?
Или правильнее "многабукавниасилил"?
декабря 2, 2007 в 2:07 pm
мы спорим об опенсорс или влеосипедах?
декабря 2, 2007 в 3:10 pm
"более чем гибкий" --- это жидкий?
IBM очень хорошо сделали, что разделили IDE на разные проекты в рамках слоистой архитектуры. Это дает возможность использовать SWT вместо обычного Swing, правда ценой привязки продукта к самому eclipse, что не всегда хорошо.
декабря 2, 2007 в 7:01 pm
Немного про Eclipse :
http://eos.sourceforge.net/
декабря 3, 2007 в 2:27 am
Fritz, перед кем отвечать? Кто пахан?
На опенсорцовые ЦМС посмотри изнутри 
декабря 3, 2007 в 2:36 am
я колупаю изнутри вордпрес, например.
Как по мне, но нормально собран и в рамках своей задачи - блога, хорошо масштабируется и легок для подпиливания.
декабря 3, 2007 в 4:44 am
Ну это смотря с какой стороны посмотреть. На неделе пробовал в него вписать функционал типа того что на фуджифото.ком.юа, а нифига - забил на это. При этом задача довольно типичная.
декабря 3, 2007 в 11:32 am
какая задача?
декабря 3, 2007 в 11:53 am
Про ЦМС никто не говорил, сабж прежде всего фреймворки, вот пожалста можно написать отценку их неимоверной кривости.
Суть разницы - ЦМС есть как товар ибо это готовое решение, фреймворк - редкость, первый пост о фреймворках.
Отвечать перед общественностью здесь - в виде обзора и демонстрации их кострубатости.
декабря 3, 2007 в 4:03 pm
Rayan, я ж написал задачу. Заливка фоток для студии фотопечати. Не, я понимаю что для этого можно приспособить какуюто галерею или аплоадмодуль, но это должно быть максимальнопросто любому зверю.
Fritz, фреймворки накладывают на программера определённые ограничения и требования к его коду. Зачастую количество этих самых ограничений и требований настолько велико, что кодер просто теряеццо. Когда проектировал свою хреновину основной задачей было максимально развязать руки кодеру, тоесть чёб он не думал каким образом ему писать. Итог? При создании модуля есть всего 3 требования, а остальное можно писать как заблагорассудиццо.
декабря 3, 2007 в 5:05 pm
> фреймворки накладывают на программера определённые
> ограничения и требования к его коду
скорее, требуют этот код структурировать
декабря 3, 2007 в 5:50 pm
Уууууу как страшно.....
Да следование паттерну МВЦ это есть страшное и ужасное ограничение связывающее бурную фантазию по рукам и ногам.
Какие требования к коду ,конкретно можно привести пример?Тока такие что от них "кодер часто теряется".
декабря 3, 2007 в 6:43 pm
ну есть тут доля правды.
чтобы в шаблоне запрос в базу сделать напрямую или из формы данные обработать то под фреймворком надо извращатсья
декабря 3, 2007 в 10:34 pm
Rayan, не надо извращаться
надо понимать ту часть архитектуры каркаса, с которой работаешь, и только то...
GeX, пока проектные решения будет принимать кодер, будет скулеж почему все каркасы "костурбатые" (интересно было бы глянуть конкретный пример "костурбатости").
декабря 3, 2007 в 11:25 pm
Роман издеваеццо и иронизирует
декабря 4, 2007 в 9:03 am
zeroreturn, например когда движ проповедует тот же xslt в шаблонах, а я люблю смарти. Выходов 2 - или ломать себя, или писать поддержку. Апи для работы тоже невсегда удобно. Ну привык я что мне те же результаты выполнения уже на блюдечке преподносят и не надо никаких фетчей, сайзов и прочей мудотни - разгрёб массив объектов хоть даже внутри шаблона и пошел дальше.
декабря 4, 2007 в 11:17 am
На самом деле вариантов масса - использовать другой фреймворк, выучить xslt, разобратся как устроен фреймворк и написать ему другой слой представления если уж такое могучее желание использовать Smarty(непонятно правда зачем :))....
Конкретно Smarty полезен когда пишешь на пустом месте, в противном случае это прокладка ненужного слоя - конструкции циклов, условий, и.т.п.язык сам имеет, а виджеты в нормальных фреймворках свои.
декабря 4, 2007 в 11:17 am
Ребята, расслабтесь немного
Этот пост о т.н. вечных вопросах на которые нет прямого ответа. Как говорят на вкус и цвет... фреймворков нет. Кто с чем работал или начинал работать, то для него роднее и дороже.
Скажу мое мнение по этому вопросу (ведь у каждого свое и это правильно, мы не запрограммированные роботы) - для небольших проектиков, на 1-2 программиста и верстальщика достаточно иметь свой фреймворк (желательно при условии что его разрабатывали все программисты), т.к. это дает быструю реализацию продукта и + если что-то надо дописать.
Но когда вопрос стоит о командной разработке людьми разного уровня, для средних и више проектов с большими нагрузками, то тут большой бизнес риск для компании. Если уволяться несколько программистов, то разбираться в том что они делали следую всего 3 (трем !!!) требованиям думаю будет проблематично. Ведь для того и делаеться куча работ по стандартизации чтобы как-то унифицировать разработку, использовать повторно и устранять ошибки.
В нашей компании используеться фреймфорк Симфони, под него велась разработка для CNN, NBA, портала фоток и видео и т.д. где нагрузки огромные, распределенная обработка (около 20 серверов) и т.д. К этому добаляеться совместная разработка с американцами. Так что не трудно представить операцию загрузки слияния изменений. Кэширование, изменение БД одной строкой, широкие возможности настройки, тестирование, MVC архитектура, строгий объектный подход, автоматическая валидация, расширяемость плагинами а также много чего другого, что создавалось тысячами людей для ускорения процеса разработки.
В итоге собственный разработанный фреймворк будет похож на то, что было в современных фреймворков годы назад.
GeX, конечно же я не умаляю никаким образом ваших способностей, возможно мы услышим новое имя, но если надо создать средний проект с нуля и командой, то стоит хотя бы присмотреться и попользоваться сторонними решениями которые уже зарекомендовали себя.
Мой взгляд сейчас на Симфони намного положительнее чем был когда начал его изучать, хотя для мелочи все равно буду использовать пока свое. Мы сначала потренировались с Симфони на админской части, а далее уже при разработке фронта были во всеоружии. И сейчас акцентируешся только для разработки функционала, механизмы работы фреймворка ясны и прозрачны.
Все выше описанное попрошу принимать за мое личное мнение, хотя от конструктивной критики не откажусь
декабря 4, 2007 в 11:38 am
+1 что еще сказать
декабря 6, 2007 в 3:12 am
Сторонникам писанины с нуля.
Нечем занятся, вы на ставке и не имеете прибыли в компании, пишите.
Это ваш хлеб на ближайшие годы, так как писать будете много и в основном ненужный никому в дальнейшем бред.
А компаниям, у которых есть подобные сотрудники - проведите беседу, увольте если не понимают. Вы просто тратите свои ресурсы. Тупо и бездарно. Риски несравненно высокие. Недаром даже монстры ПОстроения предпочитают использовать готовые решения (в том числе opensource), а не тратить время впустую...
Магу напесать афегена крутай фряймворк, он будить дажи кручи высти...
Нет, если вам жмет карман, то пожалуйста. Может и я чем сгожусь
декабря 6, 2007 в 11:31 am
правильно, гоните их вшею... они только бабки просажуют... ненадо такое... и вас "ни разу не постигнет" судьба "казино мисто" или "ваш дом" (ну пожадничал заказчик, че тут скажешь)... нихуя ниразу
декабря 6, 2007 в 12:10 pm
То, что эти компании не используют внутреннюю службу информационной безопастности это их личная проблема. Крупные фирмы всегда перестраховываются от подобных выпадов со стороны уволенных программистов, администраторов... Поэтому там такие мульки не пройдут. Некоторые пробовали "отомстить". Потом долго зубы и кости лечили. Так что все зависит от того на кого нарветесь.
ИМХО не следует так себя вести с заказчиками. Заказчик всегда прав. Даже когда он неправ 
декабря 6, 2007 в 2:12 pm
А я бы прогонял тех людей которые ничего не хотят написать своими руками
Зачем таких держать? Это же бездари. Тогда можно индусов нанимать - и дешевле и они будут безгранично рады.
Конечно не может маленькая компания себе позволить разрабатывать монстроузный фреймворк. Все правильно, надо брать готовый, если таковой уже имеется и если он качественный.
Но, категорически заявлять, что ничего самому писать не надо, лишь бери готовое и все - это не правильно.
декабря 6, 2007 в 2:28 pm
Int, там случай другой. Автор там ни при чем, просто бюджет был крайне низким, а посему сайты пустили на смолнюке. Ессно смолнюк - один бальшой дыра. На спике почитай в общем тему
декабря 6, 2007 в 3:07 pm
> что ничего самому писать не надо, лишь бери готовое и все
с "готовым" фреймвоком всеравно нужно писать
декабря 7, 2007 в 12:08 am
> правильно, гоните их вшею... они только бабки просажуют...
Таки да, просаживают заместо решения поставленной задачи, если только компания не зарабатывает на разработке фреймворка. А просаживают по тому что:
а) как уже сказали, написать очередной Symfony, Spring, Qt, .NET, и т.п., потребует затраты большого кол-ва человеко-часов, если не человек-лет;
б) обсуждая данный вопрос, тут никто не вспомнил о том что на качественную отладку вашего кода опять же уйдет большое кол-во человеко-часов, иначе будет "один большой дыра";
в) и как уже отмечали выше, если хочется чтобы не приходилось заново переписывать фреймворк если увольняеться кто-то из разработчиков много времени потребуеться на подробное документирование кода.
Соответственно время и деньги будут потрачены не на написание ПО для клиентов и получение за это денег, а на фреймворк. Написание с нуля оправданно только при решении специфических задач, для которых готовые либо отсутствуют, либо адаптация готовых решений под задачу будет неоправданно экономически и по времени.
> А я бы прогонял тех людей которые ничего не хотят написать своими руками Зачем таких держать? Это же бездари. Тогда можно индусов нанимать - и дешевле и они будут безгранично рады.
А зачем вместо решения задачи в сотый раз переписывать то что уже написали и отладили другие?
декабря 7, 2007 в 2:10 am
В одних випадках краще опенсорс, в інших - написання свого, а іноді - покупка готового рішення.
Критерії - технічні та економічні вимоги до проекту.
Варіанти з моєї практики:
1. Серія простих структурно подібних сайтів-візиток з мінімальною автоматикою. Рішення: написати самому простенький движок.
2. Невеликий портал з досить великою кількістю функцій, некомерційний або малобюджетний. Рішення: GPL-движок легкий для модифікацій.
3. Банерообмінна мережа стандартного функціоналу мало- або середньобюджетна. Опенсорс відсутній (є непридатні для використання зачатки), комерційна версія від 10000 євро за інстал. Рішення: власний движок.
4. Середній-великий портал з нестандартним функціоналом, з необхідністю частих модифікацій та часткового масштабування. Опенсорс - відсутні прямі аналоги, для близьких необхідні принципові модифікації, скоріш за все важчі ніш написання "з нуля". Рішення: свій движок.
Зі свого досвіду: час на модифікацію "свого" коду приблизно в 3 рази менший ніж на модифікацію нормального чужого.
декабря 8, 2007 в 12:02 am
Решение использовать "чужой" код или нет можно представить как булевскую фукнцию
F(3rdp, slf) = t(3rdp) < t(slf)
t(x) = tl(x) + ti(x) + r(x) + br(x)
где
3rdp - сторонняя технология (third-party)
slf - собственная технологя (self-made)
t - общее врямя потраченное на проект с использованием технологии x
tl - время обучения (time learning)
ti - время реализации (time implementing)
br - бизнес-требования на выбранной технологии (business requirements)
r - риск потери времени на выбранной технологии (risk)
дальше получаем
tl(3rdp) + ti(3rdp) + r(3rdp) + br(3rdp) < tl(slf) + ti(slf) + r(slf) + br(slf)
поскольку tl(slf) = 0, то
tl(3rdp) + ti(3rdp) + r(3rdp) + br(3rdp) < ti(slf) + r(slf) + br(slf)
обычно мы используем стабильные, хорошо документированные каркасы, поэтому
r(3rdp) << r(slf)
и как следствие
tl(3rdp) + ti(3rdp) + br(3rdp) < ti(slf) + br(slf)
если сделать допущение, что время реализации бизнес-требований на сравниваемых технологиях приблизительно одинаковое, поскольку они обе специализируются на решении наших задач (иначе зачем их вообще выбирать и сравнивать), то выходит что
br(3rdp) = br(slf)
и как следствие
tl(3rdp) + ti(3rdp) < ti(slf)
Вобщем решение писать код видимо регулируется индивидуальным порогом обучаемости кодировщика(ов) и умением оценить риск технологии.
декабря 8, 2007 в 3:08 pm
и с какого это хрена tl(slf) = 0?
декабря 8, 2007 в 3:09 pm
да, и r(3rdp) < < r(slf) — глупость
декабря 8, 2007 в 10:04 pm
почему же глупость? если каркас используется многими для решения задач, подобных твоим, от чего же риск должен быть большим?
относительно tl(slf) = 0
это какого размера должна быть технология, что бы реализовав ее, надо было ее учить 
декабря 9, 2007 в 5:55 am
итить... столько формул... а там учтено что реализованая ранее тобой технология будет юзаццо в каждом следующем твоём проекте? в этом случае уже на втором проекте система мало того что проходит обкатку, так еще и документацией обзаводиццо, притом довольно неслабой, при этом еще и наращивая библиотеку навесок.
декабря 10, 2007 в 11:47 am
И велосипед получить 4,5 и 6 колеса....
декабря 10, 2007 в 3:54 pm
и много ты GeX написал документации к своему велосипеду?
декабря 11, 2007 в 7:54 am
К самому первому велосипеду (юзал 2.5 года) на руках была подробная по апи и юзабилити. Кривой был велосипед, но если учесть что это было первое что вообще написал
... а причина написания - я его в курсаки и диплом пихнул 
... новый велосипед на данный момент находиццо на этапе жуткого кодинга и иногда перекраиваеццо даж в ядре (ща, например, надо перекроить блоковое апи и апи меню), а посему писать доку по нему просто нет резона. Дойду до точку - документирую, ибо потом и сам не пойму.
декабря 13, 2007 в 1:22 am
Q: почему же глупость? если каркас используется многими для решения задач, подобных твоим, от чего же риск должен быть большим?
Ты никогда не сталкивался с проблемами движка при реализации проекта, когда разработчик (движка) не учел одно или два тонких мест иди просто хер положил на определенный функционал? В заметке одной из основных проблем заявлена безопастность. Или с ней тоже никогда проблем не бывает? r(3rdp) много меньше r(slf)?
Q: относительно tl(slf) = 0
это какого размера должна быть технология, что бы реализовав ее, надо было ее учить 
Разработкой технологии занимается только часть команды. Сильная ее часть. Пускать в этот огород ждуниоров подобно самоубийству. А вот использовать технологию будут как раз джуниоры. tl(slf) все еще равна 0?
декабря 26, 2007 в 5:51 pm
jam>> Разработкой технологии занимается только часть команды....использовать технологию будут как раз джуниоры. tl(slf) все еще равна 0?
был описан случай, когда один человек или группа решает писать свой каркас. В твоем случае tl(slf) нулю конечно равна не будет, но ее можно сделать меньше чем tl(3rdp), поскольку все авторы технологии рядом, могут на словах объяснить, рассказать и проч. Можно подключать джуниоров к обсуждению разрабатываемой технологии. В общем случае, при грамотном подходе tl(slf) < tl(3rdp)