Честно? Это исходит из моих исследований реальности. В физическом мире много ограничений — ограниченные скоростью передатчики (свет, волна), законы преобразования приложенной силы, потери и искажения сигнала. Чтобы "коснуться" материальных деталей (планет, например) на большом расстоянии, придется проделать длинный props drilling, при этом актуальность сигнала уже пропадет и не будет отражать первоначальное намерение, потому что его источник уже мог перестать существовать.
При этом общее состояние мира является сбалансированным и стабильным, изменения в одной области в любом случае повлияют на все остальное, из чего я делаю вывод о "глобальности состояния", но несовершенстве его синхронизации. В программировании я преодолеваю эти несовершенства драфтово называемой "портальной архитектурой", когда есть единый целостный стейт, к которому может "портально" (react context + observer) подключиться любой видимый (view) или невидимый (side effect) потребитель, при этом изменения в хранилище моментально (синхронный event emitter) распространяются до тех потребителей, которым нужны конкретно эти данные (reaction subscribe). Так достигается целостность всей системы, максимальная скорость, независимость состояния и при этом его синхронизированность с отображением.
Почему это проще? Потому что не нужно получать стейты от неограниченного количества источников и синхронизировать их, как-то из props+local state+global state, у которых разные механизмы передачи информации и разные жизненные циклы. Почему проще именно в разработке? Потому что не нужно создавать цепочку передачи информации, которая приводит к ререндеру всех передатчиков и нестабильности финальных данных (проходя через props нескольких компонентов велик соблазн их модифицировать, что встречается повсеместно; из реальности — свет фильтруется, искажается его направление, рассеивается).
Хотя я не так давно практикую этот паттерн, пока не натыкался на те недостатки, которые вы предсказываете в виде потребления данных и их изменения теми, кому это не нужно — если не нужно, то компоненты и сайд-эффекты просто не подписываются на данный набор данных. Это не произвольные, а очень прямолинейные взаимосвязи — как ветки, листья и плоды присоединяются к единому стволу дерева, но каждый берет то, что нужно именно ему, и отдает то, что подходит всей системе (энергия из преобразованного листьями света).
А вот с локальными стейтами, хотя у вас и не так, так как тщательно следите в команде за изолированностью и иерархичностью, часто растет количество горизонтальных связей и дубляж, ограничивая возможности по выделению четких слоев и реальной изоляции компонентов, а не создания толстых взаимосвязанных структур, в которых перемешан и стейт, и сайд-эффекты, и синхронизация интерфейса.
Я думаю, что не только в программировании, но и в реальности за этим подходом будущее. Проводятся исследования со связанным фотонами, которые моментально реагируют на изменение характеристик друг друга вне зависимости от расстояния. Так, сейчас радиовышка вынуждена распространять сигнал по всем направлениям, что вызывает необходимость повышенного энергопотребления и ведет к ослаблению сигнала. Если сигнал нужен конкретному приемнику на большом расстоянии, то приходится вычислять его относительное расположение и передавать узконаправленный сигнал (props drilling, иерархичная связь между компонентами). Если бы приемник мог реагировать на сам факт подачи сигнала и синхронно воспроизводить его без искажений, то расположение, рассеивание, помехи ушли бы в прошлое. При наличии такой технологии единственный проблемный момент — авторизация, получение прав на синхронизацию с сигналом, та самая "изоляция", о которой вы так много говорите, но я не вижу в контексте фронтенда необходимости в подобном. Пусть каждый компонент-приемник потребляет ту информацию, которая ему нужна для функционирования. Если наткнусь на ограничения данного подхода, то первым скажу о них, но пока не сталкивался.
Неплохо…
… представим, что из всех инструментов разработчик знает только чайник. ПМ ставит задачу проекта — принять роды. Казалось бы при чем тут чайник, но вспоминаем что разраб владеет только чайником. Аналитика нет, или он занят, и нормальный процесс детализации требований невозможен. Хорошо что на старте приходит уточнение, роды надо принять у жирафа. Или у дельфина. Пока непонятно. ПМ пристал как банный лист с требованием дать оценку трудоемкости работ, он не виноват, он без неё не может посчитать стоимость, которую надо отдать сейлзу, чтобы он накрутив маржу озвучил цену договора. Чисто теоретически чайник подходит для принятия родов, но раньше так никто никогда не делал. Что ж, для оценки трудоемкости надо декомпозировать цель на задачи и понять какие другие ресурсы могут потребоваться. Для жирафа наверное нужна стремянка, для дельфина — маска и ласты. Интересно, удастся провести нормальное тестирование, или сразу в продашен? Предположим, для жирафа это займёт 100 часов, а для дельфина 180ч, ну там другая среда и вообще они скользкие. Цена договора определёна, обьявлена и обмыта сейлзом совместно с заказчиком, сроки тоже определены, и что неудивительно — сроки никак не коррелируют с действительностью и всякими там ограничениями типа срока беременности.
Беда ждет всех.
Заказчик с трудом понимает как он будет использовать младенца жирафа. Или дельфина.
Сейлз совершенно не уверен, что проект впишется в бюджет и у него будет бонус.
ПМ ничего не соображает в чайниках, жирафах и дельфинах, но очень надеется что по ходу проекта во всем разберется.
Разработчик… этот в любом случае будет во всем виноват вне зависимости от результата, но опыта ему не занимать, он привык, он прорвется.
А где вы читаете про цены в США? Читать надо там, где они соответствуют действительности. Хотите сравнить цены на товары? Ну посмотрите на amazon.com и сравните с ozon.ru, например. Если интересует «из рук в руки» — сравните ebay и avito. Еда? Сходите на grocery.walmart.com и сравните с Пятерочкой у дома или где вы там еду берете. Недвижимость — cian.ru и zillow.com. Машины? cars.com и auto.ru. И т.д. и т.п.
Вы убедитесь, что цены в России и в США внезапно вполне сравнимы. И 15к долларов, которые автор и его семья тратят в месяц — это королевский уровень жизни. И на то, чтобы жить в Москве с тем же уровнем потребления, вам понадобятся те же 15к в месяц.
Собственно, затем, что всем нужен mvc на фронтенде) А нужен он потому, что все хотят пилить интерактивные онлайн-приложения. А пилят их в вебе потому, что иных нормальных платформ для онлайн-приложений не существует. А не существует их потому, что все уже обмазались костылями вокруг веба (кратким описанием костылей и является данный пост) и привыкли ко всему этому. А потом простейшие мессенджеры кушают по несколько гигабайт памяти и половину ядер процессора. Вот так и живём
Вклинюсь с кратким ответом на «быть мудаком»:
Нет, не надо быть мудаком. Нужно уважать себя. Мудаки уважают, поэтому у них с бизнесом получается хорошо. Но необязательно неуважать других, чтоб быть успешным.
Собственно, статья отчасти об этом. Из других доказательств — книги Джона Коллинза, где один из основных выводов — уважать других, особенно своих сотрудников.
Если говорить про школьное образование, то у нас творится полный бардак. Большинство выпускаемых школьников едва ли готовы к жизни, среднестатистические общеобразовательные школы вообще не могут подготовить качественных абитуриентов, только профильные школы и лицеи, а также же дополнительные репетиторские занятия (я вообще не знаю, сейчас вообще есть дети, которые не занимаются с репетитором?).
В универах бардак еще больший. Система бакалавр-магистр, как я понимаю, помимо дипломов и возможности свалить заграницу после 4 курса, должна была сместить фундаментальные науки с первых курсов к магистратуре. И это логично, потому что первые курсы людям преподают окрестности точки эпсилон и прочую малопонятную чушь (именно так кажется на тот момент), а когда дело доходит до специальности, курсе на 4-5, людям уже на это пофиг, половина просто работает и на пары не ходит. В итоге получаем специалистов (а сейчас — бакалавров и магистров), которые, по факту, специальность пробили, а вышмат уже не помнят. А когда их вдруг заносит в области с математикой (аналитика, гейм-дев, научные расчеты и прочее), то знания все равно приходится обновлять и вспоминать. То есть не может человек после вуза начать работать в полную силу, его там просто этому не научили. На собственном опыте приема кадров в наш отдел могу сказать, что лучше брать студента курса 4-5 и натаскивать их за относительно маленькие деньги, к выпуску будут уже крутые спецы, чем брать выпускников, которые, по факту, на уровне тех же студентов 4-5 курса, но бабла хотят в 3 раза больше.
Крутые российские вузы круты не потому, что там круто преподают (это, как раз, для крутых вузов скорее редкость), а потому что в целом выборка студентов по интеллектуальным способностям там на две головы выше средних студентов других вузов. Никаких оптимизаций, никакого логичного процесса обучения, никаких интересных проектов, курсовых и прочего за время обучения обычно нет. Да, если вертеться во всей этой кухне, можно примкнуть к кружку робототехники или радиоэлектроников, но так делает 1 человек из группы.
Но а самая большая жопа в том, что российские вузы как-то не заинтересованы в разработках. Все ждут заказа от Роснефти, Газпрома и прочих крупных компаний, которым просто по долгу службы нужно всякие НИОКРы спускать в универы. Причем, в результатах работ никто не заинтересован, поэтому заполняются формальные документы, выполняются формальные работы, происходит обмен денег и на этом все.
С другой стороны, возьмите американские вузы. Может быть, они не решают задачи быстрее всех на олимпиадах, но просто тысячи разработок из американских вузов в последующем становятся нашей окружающей действительностью. Есть идеи, работы, зарплаты, инвесторы, патенты и желание получить готовых работающий продукт. У нас всего это нет (или почти нет), поэтому заниматься наукой и разработкой в отечественных вузах просто нет смысла. Поэтому, в общем-то, все эти наши олимпиадники через 5-10 лет окажутся в штатах.
Из крутого, что сейчас есть у нас — это понимание больших компаний, что вузы бесполезны в том формате, в котором они есть. Поэтому появляются всякие ШАД, Технопарки и прочие обучающие школы. Но минус в том, что их крайне мало, они локализованы, как правило, в Москве, туда высокий конкурс. Ну и понятно, что большие компании учат столько людей, сколько нужно именно им. Обучать будущих специалистов Гугл им как-то не с руки (хотя так, конечно, зачастую и получается).
Вышло так, что в той самой компании, про собеседование в которой я писал, спустя 2.5 года, случились аналогичные перемены.
Руководство сменилось, адекватные люди ушли, пришел руководитель с авторитарным стилем, нанял неопытных, но послушных «мальчиков и девочек», которые работали вдесятером за двоих и получали зарплату двоих, поделённую на всех.
Сильно сжались сроки выполнения, из решения в спешном порядке выбросили «лишние красивости» (это была автоматизация учета оборотной тары), и в результате компания выставила на рынок явно сырое, неудобное и недоработанное решение, которое, к тому же, сопровождалось на редкость «не по-русски» написанной документацией — «мальчики и девочки» писали её так же, как в институте рефераты.
Первое внедрение совершенно честно завалили. Клиент остался недоволен и — более того — обманут в ожиданиях.
Я виню себя за это, потому что на тот момент не совсем понимал, что причина — именно в отношении людей к тому, что они делают и как. Я тем временем пытался достучаться до руководителей и разъяснить им, почему это решение не будет работать и пользоваться спросом. Те, в свою очередь, искренне недоумевали, почему меня вообще это волнует. Все запросы на изменения отвергли, но по принципу «инициатива наказуема» поставили ответственным за внедрение.
Что ж? Окей, хотя бы так.
Тогда я решил пойти на принцип. Решение, вышедшее из моих рук, должно принести людям облегчение и радость, иначе оно просто не нужно.
Пользуясь тем, что руководство не сильно разбиралось в тонкостях разработки, я взял неделю времени на «доработку решения под ТЗ» очередного клиента.
На самом деле доработки там было на полдня, а всё остальное время моя группа занималась юзабилити, а я сам — писал совершенно другую, альтернативную документацию, которая вообще нигде и никак по документам не проходила. Кроме того, разработали сценарий обучения пользователей, который иначе заключался бы в тупом показе слайдшоу.
На внедрения ездил сам, пользуясь тем, что ответственный за них. Там давал юзерам свою документацию, открытым текстом рекомендуя «официальную» забросить на полку и забыть. С пользователями сами ходили по складам и учили их все делать.
Итог — 6 замечательных внедрений, клиенты счастливы, решение помогло, сократили издержки.
Если бы руководство знало, что я делаю, меня бы выгнали в тот же день. Но мне не стыдно, потому что миру стало легче и радостнее без ущерба для компании и с сохранением дохода для себя.
Сейчас я уже ушел оттуда, потому что нашел, где еще применить силы. Вместе со мной ушли еще 5 адекватных сотрудников. После нашего ухода отдел практически развалился. Руководство интересуется, почему. Я отмалчиваюсь. Всё уже давно сказал. Не поняли. Пусть учатся.
Теперь к вопросу, зачем бы это мне всё надо? Благодаря этим внедрениям я нашел десять хороших друзей среди клиентов и поставщиков. Теперь они мне помогают.
Но главное, что люди, которые получили нормальные, доработанные решения, не теряют лишнее время и экономят деньги, которые у них остаются для развития, для личного роста, для семьи и близких людей.
Спорное утверждение. Я закончил один из двух ведущих ВУЗов Нижнего Новгорода с двумя тройками, которые получил еще на первом курсе. Без единой пересдачи. При этом, я с середины третьего курса работал один период(3 месяца), по 30 часов в неделю. Потом по 40 часов в неделю. Я находил где-то эти 40 часов, так вот почему бы не работающему студенту не найти хотя бы половину этого и не поучаствовать в Open Source?
Да, мои университетские знания хуже, чем у тех 3-4 ребят, кто вкалывал все 6 лет. Я же сдавал университетский минимум и остальное получал на работе. Но процесс получения знания гораздо приятнее в то время, когда ты можешь не беспокоится на что ты будешь жить. Поэтому, я считаю, что лучше немного пренебречь знаниям университетскими в угоду опыту разработки.
Это ваш опыт. Мой опыт иной: я получал знания в университете, работая над интересными проектоми. У меня не было необходимости идти подрабатывать, потому что я получал стипендию и я знал, что если учиться не буду, то стипендии лишусь, а подрабатывать тоже не буду успевать и в итоге у меня не будет ни знаний ни опыта. А если и будет опыт, то фундаментальных знаний точно не появится. У нас есть на работе парень, который забивал на универ, а подрабатывал в это время в местной турфирме, клепал сайтик для них. Скажем так, я и некоторые другие не находим его хорошим джунеором даже спустя год.
>правильно — лучше побухать, потрахаться и на гитаре поиграть, пока здоровье позволяет, а проф знания можно и после 25 начать получать.
Хотя я этого не имел ввиду, т.к. сам не бухаю и не играю на гитаре, но одинокими или разведанными люди становятся в том случае, если забили на молодость и личные интересы помимо программирования. А программисты — группа риска по «сидению в своем мирке»
На самом деле Prolog — интересная игрушка для обучения, но как практический инструмент — он оставляет желать лучшего. Ибо провоцирует неряшливое программирование. Причём даже в этом примере это видно. Обратите внимание на то, что solution перебирает все возможные горизонтали, а не только те, которые ещё неиспользованы. Попробуйте внести коррективы — и вы увидите что красота и простота куда-то исчезают и код всё больше начинает описывать не задачу, а её решение. То же произойдёт и при более невинном действии: обобщении на доску NxN. А ведь задача-то просто идеально ложится на парадигму Пролога! А попробуйте написать на Прологе программу, решающую известную головоломку пятнашки и сравните её с версией на C++ — там уже далеко не факт, что решение на Прологе будет визуально изящнее и проще для понимания…
P.S. Видел в обной книжке по Прологу как сортировку порождали из двух процедур: одна — описывала все перестановки, другая — описывала отсортированные массивы. Несомненно решение работает, но… в учебнике какого ещё языка вы можете обнаружить алгоритм сортировки со сложностью O(N!)??? Вот эта сортировка для меня и осталась символом Пролога: языка, который может быть простым, красивым, изящным… или быстрым и эффективным — но не одновременно!
Я просто оставлю вам одну главу из книги «Язык программирования D» от Андрея Александреску:
5.11.1.1. «Чист тот, кто чисто поступает»
По традиции функциональные языки запрещают абсолютно любые изменения, чтобы программа могла называться чистой. D ослабляет это ограничение, разрешая функциям изменять собственное локальное
и временное состояние. Таким образом, даже если внутри функции есть изменения, для окружающего кода она все еще непогрешима.
Посмотрим, как работает это допущение. В качестве примера возьмем наивную реализацию функции Фибоначчи в функциональном стиле:
ulong fib(uint n) {
return n < 2 ? n : fib(n - 1) + fib(n - 2);
}
Ни один преподаватель программирования никогда не должен учить реализовывать расчет чисел Фибоначчи таким способом. Чтобы вычислить результат, функции fib требуется экспоненциальное время, поэтому все, чему она может научить, – это пренебрежение сложностью и ценой вычислений, лозунг «небрежно, зато находчиво» и спортивный стиль вождения. Хотите знать, чем плох экспоненциальный порядок? Вызовы fib(10) и fib(20) на современной машине не займут много времени, но вызов fib(50) обрабатывается уже 19 минут. Вполне вероятно, что вычисление fib(1000) переживет человечество.
Хорошо, но как выглядит «правильная» функциональная реализация Фибоначчи?
Переработанная версия вычисляет fib(50) практически мгновенно. Эта реализация требует для выполнения O(n) времени, поскольку оптимизация хвостовой рекурсии (см. раздел 1.4.2) позволяет уменьшить сложность вычислений. (Стоит отметить, что для расчета чисел Фибоначчи существуют и алгоритмы с временем выполнения O(log n)).
Проблема в том, что новая функция fib как бы утратила былое великолепие. Особенность переработанной реализации – две переменные состояния, маскирующиеся под параметры функции, и вполне можно было с чистой совестью написать явный цикл, который зачем-то был закамуфлирован функцией iter:
К сожалению, это уже не функциональный стиль. Только посмотрите на все эти изменения, происходящие в цикле. Один неверный шаг – и с вершин математической чистоты мы скатились к неискушенности чумазых низов.
Но подумав немного, мы увидим, что итеративная функция fib не такая уж чумазая. Если принять ее за черный ящик, то можно заметить, что при одних и тех же аргументах функция fib всегда возвращает один
и тот же результат, а ведь «красив тот, кто красиво поступает». Тот факт, что она использует локальное изменение состояния, делает ее менее функциональной по букве, но не по духу. Продолжая эту мысль, приходим к очень интересному выводу: пока изменяемое состояние внутри функции остается полностью временным (то есть хранит данные в стеке) и локальным (то есть не передается по ссылке другим функциям, которые могут его нарушить), эту функцию можно считать чистой.
Вот как D определяет функциональную чистоту: в реализации чистой функции разрешается использовать изменения, если они временные и локальные. Сигнатуру такой функции можно снабдить ключевым словом pure, и компилятор без помех скомпилирует этот код:
pure ulong fib(uint n) {
... // Итеративная реализация
}
Принятые в D допущения, смягчающие математическое понятие чистоты, очень полезны, поскольку позволяют взять лучшее из двух миров: железные гарантии функциональной чистоты и удобную реализацию
(если код с изменениями более предпочтителен).
Связан с этой темой немного, лечить людей ею увлеченных сначала тяжело, потом до самих доходит - после нескольких месяцев не собирающейся кончаться работы,
создаваемые человеком OWL и RDF - это тупик, количество связей растёт лавинообразно и оно просто не может быть фиксированным, предусмотреть описания для или даже сосчитать все варианты контекста - нереально
В открытом всем ветрам интернете гарантировать достоверность и, соответственно, применять не своё семантическое описание ресурса без трудоемкой верификации, всё равно никто не будет.
Но конечно здесь хотелось бы услышать, что об этом думают люди из Яндекса и Гугла.
Все это (OWL и RDF, SPARQL) будет иметь какой-то смысл, только после разработок и широкого внедрения жесткого стандарта автоматизированного семантического анализа, а до этого еще далеко.
Сейчас попытки выжать что-то полезное из OWL, SPARQL и RDF, больше похожи на сражение с мельницей известного сеньора из Ламанчи.
По статистике работников it не хватает, а по факту нафик не нужны. Королевство кривых зеркал блин.
Честно? Это исходит из моих исследований реальности. В физическом мире много ограничений — ограниченные скоростью передатчики (свет, волна), законы преобразования приложенной силы, потери и искажения сигнала. Чтобы "коснуться" материальных деталей (планет, например) на большом расстоянии, придется проделать длинный props drilling, при этом актуальность сигнала уже пропадет и не будет отражать первоначальное намерение, потому что его источник уже мог перестать существовать.
При этом общее состояние мира является сбалансированным и стабильным, изменения в одной области в любом случае повлияют на все остальное, из чего я делаю вывод о "глобальности состояния", но несовершенстве его синхронизации. В программировании я преодолеваю эти несовершенства драфтово называемой "портальной архитектурой", когда есть единый целостный стейт, к которому может "портально" (react context + observer) подключиться любой видимый (view) или невидимый (side effect) потребитель, при этом изменения в хранилище моментально (синхронный event emitter) распространяются до тех потребителей, которым нужны конкретно эти данные (reaction subscribe). Так достигается целостность всей системы, максимальная скорость, независимость состояния и при этом его синхронизированность с отображением.
Почему это проще? Потому что не нужно получать стейты от неограниченного количества источников и синхронизировать их, как-то из props+local state+global state, у которых разные механизмы передачи информации и разные жизненные циклы. Почему проще именно в разработке? Потому что не нужно создавать цепочку передачи информации, которая приводит к ререндеру всех передатчиков и нестабильности финальных данных (проходя через props нескольких компонентов велик соблазн их модифицировать, что встречается повсеместно; из реальности — свет фильтруется, искажается его направление, рассеивается).
Хотя я не так давно практикую этот паттерн, пока не натыкался на те недостатки, которые вы предсказываете в виде потребления данных и их изменения теми, кому это не нужно — если не нужно, то компоненты и сайд-эффекты просто не подписываются на данный набор данных. Это не произвольные, а очень прямолинейные взаимосвязи — как ветки, листья и плоды присоединяются к единому стволу дерева, но каждый берет то, что нужно именно ему, и отдает то, что подходит всей системе (энергия из преобразованного листьями света).
А вот с локальными стейтами, хотя у вас и не так, так как тщательно следите в команде за изолированностью и иерархичностью, часто растет количество горизонтальных связей и дубляж, ограничивая возможности по выделению четких слоев и реальной изоляции компонентов, а не создания толстых взаимосвязанных структур, в которых перемешан и стейт, и сайд-эффекты, и синхронизация интерфейса.
Я думаю, что не только в программировании, но и в реальности за этим подходом будущее. Проводятся исследования со связанным фотонами, которые моментально реагируют на изменение характеристик друг друга вне зависимости от расстояния. Так, сейчас радиовышка вынуждена распространять сигнал по всем направлениям, что вызывает необходимость повышенного энергопотребления и ведет к ослаблению сигнала. Если сигнал нужен конкретному приемнику на большом расстоянии, то приходится вычислять его относительное расположение и передавать узконаправленный сигнал (props drilling, иерархичная связь между компонентами). Если бы приемник мог реагировать на сам факт подачи сигнала и синхронно воспроизводить его без искажений, то расположение, рассеивание, помехи ушли бы в прошлое. При наличии такой технологии единственный проблемный момент — авторизация, получение прав на синхронизацию с сигналом, та самая "изоляция", о которой вы так много говорите, но я не вижу в контексте фронтенда необходимости в подобном. Пусть каждый компонент-приемник потребляет ту информацию, которая ему нужна для функционирования. Если наткнусь на ограничения данного подхода, то первым скажу о них, но пока не сталкивался.
Неплохо…
… представим, что из всех инструментов разработчик знает только чайник. ПМ ставит задачу проекта — принять роды. Казалось бы при чем тут чайник, но вспоминаем что разраб владеет только чайником. Аналитика нет, или он занят, и нормальный процесс детализации требований невозможен. Хорошо что на старте приходит уточнение, роды надо принять у жирафа. Или у дельфина. Пока непонятно. ПМ пристал как банный лист с требованием дать оценку трудоемкости работ, он не виноват, он без неё не может посчитать стоимость, которую надо отдать сейлзу, чтобы он накрутив маржу озвучил цену договора. Чисто теоретически чайник подходит для принятия родов, но раньше так никто никогда не делал. Что ж, для оценки трудоемкости надо декомпозировать цель на задачи и понять какие другие ресурсы могут потребоваться. Для жирафа наверное нужна стремянка, для дельфина — маска и ласты. Интересно, удастся провести нормальное тестирование, или сразу в продашен? Предположим, для жирафа это займёт 100 часов, а для дельфина 180ч, ну там другая среда и вообще они скользкие. Цена договора определёна, обьявлена и обмыта сейлзом совместно с заказчиком, сроки тоже определены, и что неудивительно — сроки никак не коррелируют с действительностью и всякими там ограничениями типа срока беременности.
Беда ждет всех.
Заказчик с трудом понимает как он будет использовать младенца жирафа. Или дельфина.
Сейлз совершенно не уверен, что проект впишется в бюджет и у него будет бонус.
ПМ ничего не соображает в чайниках, жирафах и дельфинах, но очень надеется что по ходу проекта во всем разберется.
Разработчик… этот в любом случае будет во всем виноват вне зависимости от результата, но опыта ему не занимать, он привык, он прорвется.
Но жирафа жаль. Или дельфина.
Вы убедитесь, что цены в России и в США внезапно вполне сравнимы. И 15к долларов, которые автор и его семья тратят в месяц — это королевский уровень жизни. И на то, чтобы жить в Москве с тем же уровнем потребления, вам понадобятся те же 15к в месяц.
Нет, не надо быть мудаком. Нужно уважать себя. Мудаки уважают, поэтому у них с бизнесом получается хорошо. Но необязательно неуважать других, чтоб быть успешным.
Собственно, статья отчасти об этом. Из других доказательств — книги Джона Коллинза, где один из основных выводов — уважать других, особенно своих сотрудников.
Если говорить про школьное образование, то у нас творится полный бардак. Большинство выпускаемых школьников едва ли готовы к жизни, среднестатистические общеобразовательные школы вообще не могут подготовить качественных абитуриентов, только профильные школы и лицеи, а также же дополнительные репетиторские занятия (я вообще не знаю, сейчас вообще есть дети, которые не занимаются с репетитором?).
В универах бардак еще больший. Система бакалавр-магистр, как я понимаю, помимо дипломов и возможности свалить заграницу после 4 курса, должна была сместить фундаментальные науки с первых курсов к магистратуре. И это логично, потому что первые курсы людям преподают окрестности точки эпсилон и прочую малопонятную чушь (именно так кажется на тот момент), а когда дело доходит до специальности, курсе на 4-5, людям уже на это пофиг, половина просто работает и на пары не ходит. В итоге получаем специалистов (а сейчас — бакалавров и магистров), которые, по факту, специальность пробили, а вышмат уже не помнят. А когда их вдруг заносит в области с математикой (аналитика, гейм-дев, научные расчеты и прочее), то знания все равно приходится обновлять и вспоминать. То есть не может человек после вуза начать работать в полную силу, его там просто этому не научили. На собственном опыте приема кадров в наш отдел могу сказать, что лучше брать студента курса 4-5 и натаскивать их за относительно маленькие деньги, к выпуску будут уже крутые спецы, чем брать выпускников, которые, по факту, на уровне тех же студентов 4-5 курса, но бабла хотят в 3 раза больше.
Крутые российские вузы круты не потому, что там круто преподают (это, как раз, для крутых вузов скорее редкость), а потому что в целом выборка студентов по интеллектуальным способностям там на две головы выше средних студентов других вузов. Никаких оптимизаций, никакого логичного процесса обучения, никаких интересных проектов, курсовых и прочего за время обучения обычно нет. Да, если вертеться во всей этой кухне, можно примкнуть к кружку робототехники или радиоэлектроников, но так делает 1 человек из группы.
Но а самая большая жопа в том, что российские вузы как-то не заинтересованы в разработках. Все ждут заказа от Роснефти, Газпрома и прочих крупных компаний, которым просто по долгу службы нужно всякие НИОКРы спускать в универы. Причем, в результатах работ никто не заинтересован, поэтому заполняются формальные документы, выполняются формальные работы, происходит обмен денег и на этом все.
С другой стороны, возьмите американские вузы. Может быть, они не решают задачи быстрее всех на олимпиадах, но просто тысячи разработок из американских вузов в последующем становятся нашей окружающей действительностью. Есть идеи, работы, зарплаты, инвесторы, патенты и желание получить готовых работающий продукт. У нас всего это нет (или почти нет), поэтому заниматься наукой и разработкой в отечественных вузах просто нет смысла. Поэтому, в общем-то, все эти наши олимпиадники через 5-10 лет окажутся в штатах.
Из крутого, что сейчас есть у нас — это понимание больших компаний, что вузы бесполезны в том формате, в котором они есть. Поэтому появляются всякие ШАД, Технопарки и прочие обучающие школы. Но минус в том, что их крайне мало, они локализованы, как правило, в Москве, туда высокий конкурс. Ну и понятно, что большие компании учат столько людей, сколько нужно именно им. Обучать будущих специалистов Гугл им как-то не с руки (хотя так, конечно, зачастую и получается).
Руководство сменилось, адекватные люди ушли, пришел руководитель с авторитарным стилем, нанял неопытных, но послушных «мальчиков и девочек», которые работали вдесятером за двоих и получали зарплату двоих, поделённую на всех.
Сильно сжались сроки выполнения, из решения в спешном порядке выбросили «лишние красивости» (это была автоматизация учета оборотной тары), и в результате компания выставила на рынок явно сырое, неудобное и недоработанное решение, которое, к тому же, сопровождалось на редкость «не по-русски» написанной документацией — «мальчики и девочки» писали её так же, как в институте рефераты.
Первое внедрение совершенно честно завалили. Клиент остался недоволен и — более того — обманут в ожиданиях.
Я виню себя за это, потому что на тот момент не совсем понимал, что причина — именно в отношении людей к тому, что они делают и как. Я тем временем пытался достучаться до руководителей и разъяснить им, почему это решение не будет работать и пользоваться спросом. Те, в свою очередь, искренне недоумевали, почему меня вообще это волнует. Все запросы на изменения отвергли, но по принципу «инициатива наказуема» поставили ответственным за внедрение.
Что ж? Окей, хотя бы так.
Тогда я решил пойти на принцип. Решение, вышедшее из моих рук, должно принести людям облегчение и радость, иначе оно просто не нужно.
Пользуясь тем, что руководство не сильно разбиралось в тонкостях разработки, я взял неделю времени на «доработку решения под ТЗ» очередного клиента.
На самом деле доработки там было на полдня, а всё остальное время моя группа занималась юзабилити, а я сам — писал совершенно другую, альтернативную документацию, которая вообще нигде и никак по документам не проходила. Кроме того, разработали сценарий обучения пользователей, который иначе заключался бы в тупом показе слайдшоу.
На внедрения ездил сам, пользуясь тем, что ответственный за них. Там давал юзерам свою документацию, открытым текстом рекомендуя «официальную» забросить на полку и забыть. С пользователями сами ходили по складам и учили их все делать.
Итог — 6 замечательных внедрений, клиенты счастливы, решение помогло, сократили издержки.
Если бы руководство знало, что я делаю, меня бы выгнали в тот же день. Но мне не стыдно, потому что миру стало легче и радостнее без ущерба для компании и с сохранением дохода для себя.
Сейчас я уже ушел оттуда, потому что нашел, где еще применить силы. Вместе со мной ушли еще 5 адекватных сотрудников. После нашего ухода отдел практически развалился. Руководство интересуется, почему. Я отмалчиваюсь. Всё уже давно сказал. Не поняли. Пусть учатся.
Теперь к вопросу, зачем бы это мне всё надо? Благодаря этим внедрениям я нашел десять хороших друзей среди клиентов и поставщиков. Теперь они мне помогают.
Но главное, что люди, которые получили нормальные, доработанные решения, не теряют лишнее время и экономят деньги, которые у них остаются для развития, для личного роста, для семьи и близких людей.
Да, мои университетские знания хуже, чем у тех 3-4 ребят, кто вкалывал все 6 лет. Я же сдавал университетский минимум и остальное получал на работе. Но процесс получения знания гораздо приятнее в то время, когда ты можешь не беспокоится на что ты будешь жить. Поэтому, я считаю, что лучше немного пренебречь знаниям университетскими в угоду опыту разработки.
>правильно — лучше побухать, потрахаться и на гитаре поиграть, пока здоровье позволяет, а проф знания можно и после 25 начать получать.
Хотя я этого не имел ввиду, т.к. сам не бухаю и не играю на гитаре, но одинокими или разведанными люди становятся в том случае, если забили на молодость и личные интересы помимо программирования. А программисты — группа риска по «сидению в своем мирке»
P.S. Видел в обной книжке по Прологу как сортировку порождали из двух процедур: одна — описывала все перестановки, другая — описывала отсортированные массивы. Несомненно решение работает, но… в учебнике какого ещё языка вы можете обнаружить алгоритм сортировки со сложностью O(N!)??? Вот эта сортировка для меня и осталась символом Пролога: языка, который может быть простым, красивым, изящным… или быстрым и эффективным — но не одновременно!
создаваемые человеком OWL и RDF - это тупик, количество связей растёт лавинообразно и оно просто не может быть фиксированным, предусмотреть описания для или даже сосчитать все варианты контекста - нереально
В открытом всем ветрам интернете гарантировать достоверность и, соответственно, применять не своё семантическое описание ресурса без трудоемкой верификации, всё равно никто не будет.
Но конечно здесь хотелось бы услышать, что об этом думают люди из Яндекса и Гугла.
Все это (OWL и RDF, SPARQL) будет иметь какой-то смысл, только после разработок и широкого внедрения жесткого стандарта автоматизированного семантического анализа, а до этого еще далеко.
Сейчас попытки выжать что-то полезное из OWL, SPARQL и RDF, больше похожи на сражение с мельницей известного сеньора из Ламанчи.