продължение

Финансовите резултати на Майкрософт и особено скок-а с 21% при сървърните им продукти (Да! Въпреки Линукс!) ме накара да се замисля и така стигнах до някои просветления, които реших да споделя с вас.

Защо след целия този шум около Линукс, Майкрософт отбелязват такъв ръст именно в сървърния си отдел? Моят отговор е следния - понеже Уин Сървър 2003 е първия application server out of the box. Имам впредвид просто го слагаш и и имаш без особени главоболия чудния им .НЕТ фреймуърк и абсолютно всичко останало каквото може да ти потрябва, за да правиш софтуер от елементарни неща до ентерпрайз решения. И това ти идва готово, с добра документация, чисто и подредено.

А сега си представете какво е ако трябва да правя софтуер с конкурентната платформа - примерно Джава под Линукс. Почва се... кой Линукс. После JDK от Сън. После? Някъв апликейшън сървър... БЕА, УебСфера? Или някви по-евтини примерно Catalina с ЖБосс. Документация? Лоша и различна - всеки вендор по различен начин документира.

Това всичкото мога да си го спестя ако отида при АйБиЕм и си накупя от тях всичко - обаче тогава цената става примерно 3-на отколкото на Майкрософт и 2-но по трудно за подръжка. И пак зависиш от само един вендор, а нали това е главната причина да се бяга от Майкрософт?

И в един момент така се получава, че е по-лесно да си почнеш проекта като пич на .НЕТ и да го деплойнеш на 2003 Сървър за 3-но по-малко време, пари и нерви. И пазара го отразява това нещо - 20% ръст за тримесечие не е малко за времената, в които се намираме.

Така че усилията на цялото Линукс общество трябва да са не към шарени интерфейси и не знам си какви си секюрити глупости, а към създаването на лесен фреймуър за правене и деплойване на приложения - нещото, което практически липсва в Линукс средите. Понеже в момента няма реална out-of-the-box алтернатива на Уиндоус сървър.

Многото пари рано или късно си казват думата. Колкото и скапани да бяха продуктите на Майкрософт, рано или късно ще успеят да направят нещо свястно. То и няма как иначе, при тези милиарди и при конкуренцията от страна на Линукс - откъде по-голяма мотивация.

Тъжното е, че множеството OS фенове не могат да се борят срещу парите на гиганта. Колкото и да са добри.

По-тъжното е, че всичко отива към монопол.

>>>По-тъжното е, че всичко отива към монопол.

Ама знаеш ли кое е интересното? Поне при сървърните ОС преди Линукс да се разпространи до такава степен имаше съвсем сериозна и реална конкуренция на поне 5-6 фирми.

Откакто се появи Линукс много малки и симпатични фирми за сървърни операционни системи фалираха - и то не заради Майкрософт, а именно заради Линукс. Сега всичко това е доста сериозно окупирано от АйБиЕм.

Аз затова тука доста сериозно се опитавам да наблегна, че АйБиЕм са по кофти копелета от Майкрософт, щото докато Майкрософт обират всякакви негативи, АйБиЕм правят абсолютно същото и хората им се кефят и пляскат.

Първо дай да спрем с фокуса върху линукс и да го разширим за свободния софтуер изобщо. Какво е различното - платформата е по-евтина, често напълно безплатна. Програмистите обаче трябва да са по-скъпи, защото често се оказва, че платформата не е на нивото на платената конкуренция. Не говоря за showstopper проблеми - просто неудобства, водещи до по-висока цена на крайното решение.

Безспорно ако тръгна да правя ентерпрайс решение с много функционалност и т.н. бих си избрал или Джава или .НЕТ. За момента не знам да има друга алтернатива, която да е толкова развита. Вярвам, че могат да се постигнат еднакви неща, но сигурно Джава програмистите ще трябва да са по-скъпи от разглезените от форм дизайнери и генерации на код момчета с майкрософтските технологии. Как да определим дали повишената цена на Джава решението си струва в по-дългосрочен план за сметка на независимостта от конкретен продавач на технологии? Как да определим дали ще излезем по-бързо на пазара ако използваме едната или другата технология? Аз май не мога да оправя уравнение с толкова неизвестни. Едно е ясно - решението да си купиш Джава сървър и/или поддръжка от IBM или някой подобен убива идеята да си независим.

Какво става обаче, ако няма нужда от разработване на огромно и сложно решение? Малко сайтче, което да продава нещо; мини интранет решенийце; няколко автоматизации покрай бизнес процеса. Тогава излиза друг сериозен конкурент - добре дошъл в PHP света. По неволя започнах да се занимавам с PHP, но открих няколко изключително важни неща за него: невероятно лесна разработка на малки неща; евтин и разнообразен хостинг; евтини програмисти; сериозна платформа, която не прави ентерпрайс функции невъзможни, а дори и да ги прави - може да се свърже сравнително лесно с решения разработвани на други платформи.

Та мисълта ми беше, че липсата на готов апликейшън сървър не е голяма болежка, защото на много хора това не им трябва. Другия въпрос е "Защо ми е да плащам за апп сървър като не ми трябва?". Пример за преоткриване на прости неща: преди мислех за MySQL с известна доза дискомфорт - абе няма вю-та, съхранени процедури, вложени заявки... Гадна работа. Когато започнах да го използвам открих, че тия работи рядко ми трябват, а освен това сървъра е обидно бърз и си върши работата страшно добре.

Ако имаш идея за това как да изчислим цената на решението с всичките плюсове и минуси в ситуациите на свободен и платен софтуер - давай. Като за начало можем да се опитаме да определим променливите, които действат на цената (крайната):
- цена на платформата, апликейшън сървъра, средствата за разработка --> Начална цена или Ц0
- цена на програмисткото време - да кажем Х лева на час --> ПЦ
- време на разработка --> В
- скрити разходи - ъпгрейди на платформата, библиотеки, операционни разходи --> СР
- поддръжка и лесно разрешаване на проблеми свързани с разработката --> да кажем средното време П за решаване на проблем
- документация и стабилност - колко пъти ще се сблъскаме със странен проблем --> ДС
- други?

Трябва ни и формула за крайната цена - нещо като:
Ц0 + ( ПЦ х В ) + ( ДС х П х ПЦ ) + СР = ?

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Ами точно това имах предвид под сполучлив фреймуърк (.NET) - такъв, който да е достатъчно мощен за ентерпрайз и достатъчно лесен за елементарни неща. Нали знаеш за Жабата лафа дето прави лесните неща трудни а трудните невъзможни.

Аз също съм писал на ПХП и MySQL и трябва да ти кажа, че след като веднъж научиш АСП.НЕТ, няма да ти се иска да се връщаш назад. Сега твоя аргумент, че много неща дето си ги ползвал преди просто не са ти трябвали не мога да го приема - примерно можеш и да не ползваш бази данни въобще, а текстови файлове примерно, ама това не значи, че е правилния и ефективен подход. Примерно вярно е че можеш да направиш проекта и без stored procedures (MySQL 3.x не ги поддържаше, сега не знам 4 как е), ама ако ги има по-добре се отделя data-access layer-a и проекта става по-лесен за писане и поддръжка.

Лично мене знаеш ли какво ми притеснява при отворения софтуер? Липсата на хомогенност. Примерно при .НЕТ/МСДН всичко е еднакво описано, направено и е доста predictable как се правят нещата, веднъж като влезеш в час. Спомените ми от Джава програмирането са точно обратни - свали тая библиотека, сложи този сървър, компилирай това - всичкото лошо и/или нехомогенно документирано и описано и това доста ме дразнеше.

Като цяло в твоето уравнение мисля най-голяма тежест има ( ПЦ х В ), а това при .НЕТ (в общия случай) съм сигурен че е в пъти по-малко отколкото Жава.

Само времето ще каже дали бъркаш или аз бъркам :)

>след като веднъж научиш АСП.НЕТ, няма да ти се иска да се връщаш назад.

Тоя аргумент съм го чувал и преди. Поразгледах малко, наистина има хубави работи, но чак такова крайно изказване не съм готов да направя.

>Сега твоя аргумент, че много неща дето си ги ползвал преди просто не са
>ти трябвали не мога да го приема - примерно можеш и да не ползваш бази
>данни въобще, а текстови файлове примерно, ама това не значи, че е
>правилния и ефективен подход.

Тук не сме се разбрали - ясно е, че като ми трябва база ще използвам и няма смисъл да се гърча с решения, които правят същото нещо, но по-зле. Само дето искам когато ми потрябва Х - да мога да си го купя отделно и да не трябва да инвестирам куп пари в някой "пакет", от който няма да ми трябва перфектната поддръжка на транзакции, например, защото става дума за малко приложение.

Липсата на хомогенност наистина е проблем за свободния софтуер. Усложнява живота на програмиста - затова и казах, че програмистите трябва да са по-скъпи. Хубавото обаче е, че имаш кода - и ако нещо не ти пасва точно можеш да си го приспособиш. Е това не е вярно за всички свободни проекти - има си и хубави и ужасни.

>Като цяло в твоето уравнение мисля най-голяма тежест има ( ПЦ х В )

Всички са ни учили в курсовете по алгоритми, че константите не влияят на сложността на алгоритъма и растежа на функцията. В някои случаи обаче това не е така - ако проекта е сравнително малък ( малко В ) тогава Ц0 е решаващ фактор. А защо ( ПЦ х В ) е с пъти по-малко при .НЕТ отколкото при Джава? Само заради нехомогенността или има и други причини?

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

BTW ... Mr. Gates е представен към Sir

-----------------------
гърбавия, ковчег ще го изправи

Това да създаваш мързелив начин на мислене у програмистите е наистина патент на MS, за да може "по-бързо и по-лесно" да напишеш неща, които работя "почти винаги" и "най-често". Оттам са се пръкнали и всички извращения на огромни по обем програми, вървящи бавно и вършещи не това, което искаш от тях. Цялостната идеология, върху която е построен бизнес и ИТ моделът на МС води до извращения от рода на описаното в четивото за домашна работа:

Apps like Excel and Access breed stupidity

В допълнение, IBM, HP, Sun, Novell и още колко народ залагат на open source основа за своите бизнес решения - сървъри и десктопи, явно са прекалено глупави, а и това да имаш един единствен доставчик на технологията си, вървяща само на една ОС (windows) е много по-гъвкаво и добро за бизнеса от това да имаш избор измежду десетина големи фирми, доставящи ти крайно решение, ready-for-deployment, базирано на Линукс.

Все пак, крайното решение какво ще купим е в ръцете на чичковците, работещи с excel.

Статията, която си посочил е писана в стил Слашдот и е забавна. Ако наистина и вярваш - значи нещо с реалността имап проблеми. Цитирам гениални фрази:

"Until then, it is back to writing Perl to deal with the stupidity that apps like Excel and Access breed . . . "
Какво общо има писането на Пърл с Ексел? Какво сравняваме, ябълки и портокали?

"...that Excel, Access, and its ilk only create drones that copy and paste all day, tend to their macros that greatly complicate "simple" programming problems..."
Пич, забрави програмирането. Ексел и Аксес имат за задача да решават бизнес проблеми и именно заради това, че няма нужда от програмиране, са толкова удобни. Какво, трябва да наемам 5 прескъпи Пърл гурута за да си сметна оборота за месеца ли?

И въобще, статията казва нещо в стил - "С Ескел и Аксес е много лесно - само копи/пейст наляво надясно и това е. Това те прави тъп".

Все едно аз да кажа "Телевизорите с пускат само с едно натискане на дистанционното. Това те прави тъп - много по-добре е да отидеш до телевизора с манивела, да въртиш пет минути докато загрее и след това да извикаш Дама Пика и тя да го пусне."

Пич, питаш каква е връзката между excell+access и perl ли

ако не знаеш, да обясня: пърл е един от лесните скрипт езици за писане на полезни и ефективни малки програмки на Н-найсет платформи (вкл. виндовс) и може да направи нужното за работата на даден офис на 100 реда код, написан веднъж и пускан с едно кликване или команден ред и автоматизиращ цялата работа по обработката на информацията, което се съпоставя с модела на E+A, където същото се прави *всеки_път* с Н-стотин кликания и импортвания от access заявки в excell таблици и последващи Н-стотин кликания за форматиране и преизчисляване, за да направиш крайня report, годен за употреба.

В статията се говори за мързеливия начин на мислене и осакатяването на потребителите, които да вършат *всичко* с примитивни средства, защото "така е лесно". Има проблеми, които се решават само със spreadsheet програми, а има и проблеми, където е по-ефективно да напишеш код, при това незадължително на VC++ или на Ц бемол

Държа да подчертая, че една от основните ми задачи в работата ми е точно това, да генерирам чрез скриптове многомегабайтови рипорти, които по-късно отиват сдъвкани и смлени до крайните win потребители и знам какво би им струвало да направят същото, ако само им пускам raw tsv files от базата и след това да ги оставя да пасат с excell

И не се изхвърляй така с изявленията, оставяй си винаги по една вратичка, да не би да се изложиш, ако не си достатъчно запознат с дадена тематика

се използвали Ексел-а и Аксес-а - "*всеки_път* с Н-стотин кликания".
Май съм открил недокументирана функционалност, която ми позволява да запазвам репортите и да ги преизползвам :))

ох... следва мрънкане.

>пърл е един от лесните скрипт езици за писане на полезни и ефективни
>малки програмки на Н-найсет платформи (вкл. виндовс) и може да
>направи нужното за работата на даден офис на 100 реда код, написан
>веднъж и пускан с едно кликване или команден ред и автоматизиращ
>цялата работа по обработката на информацията, което се съпоставя
>с модела на E+A

Дай да почнем едно по едно:
1) пърл е лесен език? хайде де - не мога да нарека "лесен" език, който има отделно мнение за екзотичните символи като $%@&, които трябва да слагам пред променливите. Как да работя с език с примитивно подаване на параметри на функциите ( говоря за ръчното измъкване от оня масив с глупавото име - май $_ беше )? Какво да си мисля за език с наследяване, което е кърпено с бели конци - ISA масива, който казва кои класове наследяваш. И кое изобщо му е по-лесното на пърла от ВБ езика например?

2) можело да прави същото като офиса и то на 100 реда. Явно не познаваш изобщо възможностите на офиса. Само за материала зад финансовите или статистически функции дето ги има в ексела сигурно ще отиде повече код.

3) предимството на пърл е преносимостта и богатия избор от библиотеки. тези предимства обаче ги имат и други по-елегантни езици - я ръби, я пайтън. пърл си има сериозни проблеми - дано ги оправят във версия 6.

Не искам да звуча като бесен фанатик - езика си има приложенията, това, че на мен не ми харесва не трябва да се натрапва. С две ръце съм за автоматизацията в офис работата. Много против съм обаче за заменянето на един вид слепота ( цъканията по ексела ) с друг вид такава ( пърл за всичко ).

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

За всяка ситуация - подходящият инструмент, нали не искаш да чупиш орехчета с парен чук? ;-)

Откъде си сигурен, че цената на IBM е тройно по-викока от тази на MS?

Вероятно е по висока, но замислял ли си се защо?
Защо цената на AMD процесорите е по-ниска от тази на INTEL, въпреки че в някой случаи производителността при AMD е по-висока?
Кратко и ясно: надеждност!
MS (поне досега) не могат да се похвалят с особена надеждност.

Ако те притеснява високата цена на IBM можеш да се престрашиш да поровиш и да прочетеш това-онова и сам да си направиш нещата. Ако не искаш да се занимаваш - можеш да платиш на някой да го направи вместо теб - все пак ако те мързи да изкараш шофьорски курсове, но ти трябва автомобил, или ще ползваш таксита или ще си наемеш личен шофьор!

Нищо лично, приятел, не искам да поглеждам едностранно на нещата. Пърл е бил готин език навремето, преди, хм, 10 години - но в момента има и по-добри алтернативи ако ще пишеш скриптове, които да работят на много платформи - Муслон ти ги е посочил, аз бих добавил PHP.

Малко overuse има при Пърл - оригинално си мисля, че е направен нещо като по-мощен шел език - после вече много лошо са го кърпили и адвали всякакви неща като Perl DBI примерно и ООП - неща дето Пърл въобще не му е работата да се занимава с тях. Освен това, честно, синтаксиса е отврат. По състезанията за obscure code Пърл решенията бият дори и хардкор С-то.

А да сравняваш Ексел и Аксес с Пърл алтернативи е, меко казано, неадекватно. В смисъл не твоя постинг, а статията, която си постнал не е адекватна. Прочети я пак - на някой Пърл гуру му е станало тъпо, че това което той е кодирал пет години с Пърл с Ексела мое да се направи за 5 мин.

Оценявам добронамереността в тона ти, за което благодаря. Все пак пърл не е нито остарял, нито е кърпен непохватно, особено що се отнася до DBI модулите и ООП - защо да не се ползва обектният подход в големи програми с UI-и и какви ли не глезотии?

В момента доста от системните tool-чета за администрация на UNIX сървисите (а и windows програмиране, защо не) са писани на пърл с gtk графични библиотеки и widget-и, друга част са правени на питон (също мощен скрипт език), а трета - на tcl/tk, отново скриптинг език.

Това дава гъвкавост, както и бързо и ефективно develop-ване на програмни средства и в никакъв случай не би могло да бъде сравнено с недомислието VB, например (no offense meant към почитатели на езика, но наистина basic не е стока)

За obscurity - съгласен съм, могат да се напишат неразкодируеми неща, особено ако се намесят regular expressions, но това не е самоцел, ако се наложи, ползва се, ако не, както е при мен, пиша по нормален начин с лесно четими похвати и изрази.

Мисълта ми при пускането на линка към статията е, че създадените програмни средства и приложен софтуер от любимата фирма създават вреден начин на мислене за самия потребител, докато се достигне до невиждани висини на неефективността. А DBI се води за един от най-бързите API-та за достъп до всякакви видове бози от данни, което събрано с мощта на програмния език води до цялостна ефективност на решаването на проблема за обработка на data от суров в краен вид, готов за ползване.

Колкото до ПХП, това е наистина мощен език и за уеб, и за приложно програмиране (с ООП, създаване на програми с gui и всичките други бонуси), моят любим език всъщност, гъвкав и удобен, вървящ на много ОС платформи, вкл. виндовс, през уеб сървър или като самостоятелен изпълним модул-интерпретатор

поздрави

Съгласен, че едно решение не е универсално и съм далеч от мисълта, че пърл е най-невероятният език на земята, не съм от основните му фенове, просто ми се налага да го ползвам в работата си често.

Гъвкавостта в мисленето е изключително ценна, това беше основната ми теза