Здравствуйте, Pauel, Вы писали:
S>>Т.к. новый человек в любом случае будет вынужден туда погрузиться, так что это можно принять за константу и не брать больше в рассмотрение.
P>Необязательно. Новый человек входит сначала в домен, как правило. Например, пока вы не сдате тест на понимание основ американского медицинского страхования, вы не узнаете каких фремворков там понамешано. Ну или вас зарежектят на собеседовании если домен ужос как надо.
Это типа противоречит тому, что я написал? Если да, то в чем, не вижу отличий.
S>>Но "Шкуры и хвосты" построили свой продукт на FFMPEG, а "Рога и Копыта" на собственной разработке, сделанной с нуля и повторяющей (по своему) нужную часть функциональности FFMPEG.
S>>Вот сложность найма в "Рога и Копыта" по сравнению со сложностью найма в "Шкуры и хвосты" и обсуждается.
P>И в чем будет отличие по вашему с т.з. рисков и сложностей?
Риски брать не буду, т.к. это очень скользкая тема и оценивать из можно по разному, в зависимости от того, какой набор факторов риска кому нравится больше.
Первая сложность, которая сходу всплывает: нужно придумать как замотивировать нового человека изучать самодельный фреймворк (особенно если предложить много денег не вариант). Одно дело пойти и изучить что-то общеупотребительное, такой опыт может пригодится и в другом месте, даже в смежной предметной области. Другое дело тратить время на то, что нужно только в "Шкуры и хвосты".
У опытных разработчиков в прошлом может быть опыт по работе с самодельными велосипедами и этот опыт может быть негативным.
Чем менее опытный разработчик, тем меньше у него опасений по этому поводу.
Следующая сложность: насколько просто погрузить человека в инструмент и сколько времени это займет, прежде чем польза он него превысит затраты на него же. У общеупотребительного инструмента есть какая-никакая документация, следы обсуждения на форумах, статьи и блог-посты, может быть даже книги или обучающие курсы (консультанты-коучи), скорее всего есть коммьюнити, к которой можно обращаться. Общеупотребительный инструмент обкатан в большем количестве кейсов и в нем можно надеяться на то, что в основных сценариях он работает хорошо (надежно, эффективно). А если проблемы находят, то есть коммьюнити, которое может помочь с найденными проблемами.
У самодельных фреймворков с этим все, обычно, гораздо хуже. Носителей информации, у которых знания можно получать, мало, они заняты. С багами разбираться придется самому (т.к. другие заняты).
Погружать джуна в самодельный фреймворк может быть проще (дешевле), чем сеньора, т.к. джуну дают более простые задачи, для выполнения которых на начальном этапе потребуются минимальные знания. Погружение джуна в фреймворк, будучи изначально растянутым на большее время, может происходить проще. Джуну может быть даже интересно в потрохах лисапеда покопаться, что-то типа вызова. Такой стимул вряд ли будет у сеньора.
Взять на работу мидла (а особенно, джуна) -- это игра "в долгую". У компании должны быть ресурсы на то, чтобы выращивать человека до высокой квалификации. В том числе и человеческие ресурсы, которые выращиванием и будут заниматься. При этом высока вероятность ошибки (особенно в случае джуна) -- вложили много сил и времени, на полноценную отдачу его не вывели, а он нашел что-то поинтереснее и свалил. С сеньором ситуация несколько предсказумее, да и отдачу он начнет давать быстрее. С другой стороны, если растить человека в компании с джуна, то затем он станет носителем нужных технической и корпоративной культуры. Со временем он может просто не захотеть рисковать все бросать и уходить с теплого места. Т.е. можно вырастить именно что "своего" сеньора.
На то, чтобы копать дальше нет желания тратить время.
Здравствуйте, Pauel, Вы писали:
P>По моему этот все тот же разговор
Нет. Обсуждая "сложность" и "риски" я всего лишь показываю еще один случай приписывания мне того, чего я не говорил.
P>Буквально — не говорите про риски.
Не говорю потому, что риски могут зависеть не только от сложности, но и от внешних факторов. Например, репутация компании, расположение офиса. Да даже курсы валют (например, искать в РБ разработчиков для компании из РФ с оплатой в RUR сейчас более рисковано, чем год назад).
P>По картинке вроде как еще 33% это объектная машина . И какие то инструментальные средства — 66%. Что там — не ясно, я бы предположил что там не квадраты, а дсл, который имеет визуальное представление.
Этот визуальный DSL -- это как раз сама Флора и есть, ее краеугольный камень и отличительная особенность. Там изначально все завязано на то, чтобы рисовать квадраты-сущности, устанавливать между ними связи и, где нужно, прописывать какие-то реакции. Для описания реакций язык, который транслируется в байт-коды их VM.
И лично я бы шел к построению чего-то подобного Флоре итерационно через бутстрапинг.
P>Теперь смотрите фокус — вот у нас есть ядро флоры и всё такое — что будет с рисками, если мы переложим вообще всю разработку на продуктовую команду и как изменится сложность найма?
Что вы называете "всю разработку"?
В 2005-ом у Компас Плюс не было сложности с наймом, т.к. они были монополистами на местном рынке труда и попасть к ним люди стремились еще будучи студентами.
Я сильно сомневаюсь, что такой фокус сработал бы у относительно небольшой компании в городе покрупнее (вроде Новосибирска, Питера, Минска).
P>Вот бы узнать, что же это люди с такой классной системой сотворили, что она исчезла.
Вопрос еще исчезла ли она. Вполне может быть себе живой и здоровой. И сметать под себя все, что появляется на рынке труда Магнитогорска.
Она и в 2005-2006 была никому не известно, а продвигать такой велосипед в массы -- это отдельная большая и крайне неблагодарная задача. Особенно с началом нулевых, когда бесплатный OpenSource начинал становиться мейнстримом.
Здравствуйте, vaa, Вы писали:
vaa> приличное приложение, например для работы с БД, т.е. с датагридами и т.п. vaa>Ели да, какие? паскаль, си, ди, зиг, раст, плюсы?
Здравствуйте, Артём, Вы писали:
А> vaa> приличное приложение, например для работы с БД, т.е. с датагридами и т.п. А> vaa>Ели да, какие? паскаль, си, ди, зиг, раст, плюсы?
А> Это перепись наркоманов?
А> Напомню, что даже этот чатик- веб приложение.
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, vaa, Вы писали:
vaa>> приличное приложение, например для работы с БД, т.е. с датагридами и т.п. vaa>>Ели да, какие? паскаль, си, ди, зиг, раст, плюсы?
Аё>Это перепись наркоманов?
Аё>Напомню, что даже этот чатик- веб приложение.
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, vaa, Вы писали:
vaa>> приличное приложение, например для работы с БД, т.е. с датагридами и т.п. vaa>>Ели да, какие? паскаль, си, ди, зиг, раст, плюсы?
Аё>Это перепись наркоманов?
Аё>Напомню, что даже этот чатик- веб приложение.
да ну? есть вроде клиент на плюсах. в любом случае, о чем это говорит?
P>>Теперь смотрите фокус — вот у нас есть ядро флоры и всё такое — что будет с рисками, если мы переложим вообще всю разработку на продуктовую команду и как изменится сложность найма?
S>Что вы называете "всю разработку"?
Вообще всё что только нужно: все фичи-фиксы ядра билды-тесты-инфраструктура, итд. Я несколько раз побывал в такой ситуации. Мне трудно понять, каким образом можно взять и начать набирать студентов направо налево.
S>В 2005-ом у Компас Плюс не было сложности с наймом, т.к. они были монополистами на местном рынке труда и попасть к ним люди стремились еще будучи студентами.
Скорее получается так, что других вариантов у людей то и не было.
S>Я сильно сомневаюсь, что такой фокус сработал бы у относительно небольшой компании в городе покрупнее (вроде Новосибирска, Питера, Минска).
Я тоже так думаю. А следовательно они выбрали определенную стратегию управления рисками — сели рядом с университетом, что бы получать непрерывный поток кандидатов.
Здравствуйте, Pauel, Вы писали:
P>>>Теперь смотрите фокус — вот у нас есть ядро флоры и всё такое — что будет с рисками, если мы переложим вообще всю разработку на продуктовую команду и как изменится сложность найма?
S>>Что вы называете "всю разработку"?
P>Вообще всё что только нужно: все фичи-фиксы ядра билды-тесты-инфраструктура, итд.
Понятия не имею как все это решено в Компас Плюс, могу лишь сказать как бы сам действовал в подобной ситуации: специализация. Т.е. есть специалисты, которые пилят Флору (разработчики, тестировщики и т.д.), есть специалисты, которые на базе Флоры делают полукоробочные решения (например, софт для интеграции банкоматов), есть специалисты, которые на базе Флоры и полукоробочных решений делают кастом по конкретного заказчика. В итоге все более-менее умеют пользоваться Флорой, но некоторые еще и знают как она внутри устроена, а другие знают как с ее помощью решать прикладные задачи.
Перевод специалистов из одной команды в другую будет сопряжен с некоторым переучиванием. Где-то переучивание будет заключаться в изучении предметной области, где-то в изучении нижележащих технологий.
P>Мне трудно понять, каким образом можно взять и начать набирать студентов направо налево.
И не нужно набирать студентов направо и налево. Надо процесс роста кадров в компании выстроить так, что крутые полуготовые спецы на рынке появляются редко, с ними можно работать поштучно. А вот джунов нужно брать с каким-то постоянным темпом с последующей выбраковкой (т.к. определенно не все вырастут в того, кто будет давать хорошую отдачу). Соответственно, должен быть какой-то поставленный процесс менторства. Должны быть средства для погружения малоопытных людей (да хоть та же документация с примерами для Флоры). Процессы разработки на разных участках должны быть выстроены так, чтобы был набор небольших и простых задач на которые можно ставить джунов с последующим контролем и обучением. И т.д., и т.п.
S>>Я сильно сомневаюсь, что такой фокус сработал бы у относительно небольшой компании в городе покрупнее (вроде Новосибирска, Питера, Минска).
P>Я тоже так думаю. А следовательно они выбрали определенную стратегию управления рисками — сели рядом с университетом, что бы получать непрерывный поток кандидатов.
Они сели, полагаю, еще во времена СССР. Либо в каком-то КБ, либо в каком-то НИИ, либо на кафедре какого-то ВУЗа. Когда Союз накрылся медным тазом, то создали компанию и начали пилить свои продукты, а на их базе -- решения для заказчиков. Причем вначале сего процесса у истоков стояли матерые профи с большим опытом за спиной, которые базу и создали. А затем уже под этих профи стали брать тех, кто еще был в наличии на местном рынке труда. И если говорить про 90-е годы (да и начало нулевых) в нестоличных регионах, то там мало кто и был-то, на этом самом рынке. В основном студенты из которых можно было отбирать самых-самых, с горящими глазами и желанием именно что программировать.
property real rotationDelta: landscapeWindow ? -90 : 0
????
Это вообще ни в какие рамки!
Декларативный язык — это XAML минус дебильные bindings. Вот он прям 1:1 отвечает чистой, незамутнённой идее "декларируем UI". А то, что создали Культи — ещё более худшее месиво, чем XAML.
О декларациях надо думать так: вот есть некое описание UI. Есть какой-нибудь тостер с 10 килобайтами ОЗУ, который хочет на 200х100 экране показать пару кнопок и лэйбл. Вот сможет такой девайс распарсить всю эту Культяшную белиберду, сгенерить код, показать UI и всё это в пределах 0.1с? Очевидно, нет.
Декларации — это строго никаких вычислений, выполнений, условий, циклов и т.п. Было бы у WPF так, его ДАВНО бы портировали на все линупсы.
Здравствуйте, Baiker, Вы писали:
B>Как можно в декларации писать B>
B>property real rotationDelta: landscapeWindow ? -90 : 0
B>
Вы понимаете что здесь происходит? Что произойдет если landscapeWindow измениться? Как бы вы хотели выразить этот код более декларативно?
B>Это вообще ни в какие рамки! B>Декларативный язык — это XAML минус дебильные bindings. Вот он прям 1:1 отвечает чистой, незамутнённой идее "декларируем UI". А то, что создали Культи — ещё более худшее месиво, чем XAML.
В чем конкретно претензия? Покажи код на XAML и QML.
B>О декларациях надо думать так: вот есть некое описание UI. Есть какой-нибудь тостер с 10 килобайтами ОЗУ, который хочет на 200х100 экране показать пару кнопок и лэйбл. Вот сможет такой девайс распарсить всю эту Культяшную белиберду, сгенерить код, показать UI и всё это в пределах 0.1с? Очевидно, нет.
Очевидно, что именно так все и работает. В реальном мире оно так:
Approximate minimal hardware requirements for running Boot to Qt are:
256 MB of RAM
500 MHz CPU, 1 GHz preferred for 60-FPS velvet-smooth UI
OpenGL ES 2.0 support *
Но это дает 60 FPS и практически любой GUI, а не только пару кнопок.
B>Декларации — это строго никаких вычислений, выполнений, условий, циклов и т.п.
И? Это и есть QML. При необходимости дополняемый императивным кодом (JS или С++).
Здравствуйте, Shmj, Вы писали:
S>Вот в том то и дело. QT добавляет много удобных фишек, фактически превращая написание кода по удобству — не хуже .Net платформы. Но за все нужно платить — по тормознутости получается не на много лучше модных языков
Чушь
S>Как то чувак рассказывал свой опыт написания ORM для C++ на QT — получилось тормознутым и смысл писать на ++ — околонулевой.
Здравствуйте, Skorodum, Вы писали:
P>>Кроссплатформенность как раз таки взлетела. UI не так что бы взлетел. В джаве по факту он даже более кроссплатформенный, чем на дотнете. S>Где эти приложения?
IDEA/Clion и тп. Классные средыТормозное говно
P>>Раньше почти весь UI пилился на плюсах. S>Delphi же.
Ну, скорее нет, или фифти-фифти. Всякое формошлепство в проектах типа самописной бухгалтерии/документооборота — да. В этом плане, кстати, билдер был неплох — и простота создания гуя, и мощь плюсиков.
Всякое коробочное, если конечно не одиночка-шароварщик — пилились на MFC в основном, или WTL, или даже чистый WinAPI
Ради интереса решил глянуть.
Есть довольно старый Photoshop, ему лет 10, если не 15. Нашел там AdobeOwl.dll, AdobeOwlCanvas.dll — название намекает на борландовскую либу OWL — Object Windows Library. Хотя, наверное это не то — там все экспорты/импорты вида OWL*, а у бормана было T* — TWindow и тп
Или ACDSee, тоже древняя. Нашел там импорты из mfc90u.dll
DipTrace — не опознал, может на WinAPI
Inno Setup — там, наверное, Дельфя... Хотя — ковырнул — на дельфю не похоже, может и опять WinAPI
NanoCAD — не опознал, но есть D3DCompiler_43.dll, d3dx9_43.dll.
XnView — не опознал
wxFormBuilder, wxPack, wxVC, CodeBlocks — понятно на чем
Stamina — MFC42.DLL
P>>Это было еще до прихода дотнета. Соответсвенно специализация "UI" в с++ можно сказать исчезла — в вакансиях ниже статистической погрешности S>На вскидку.
Ну хз. Помимо automotive, про который уже говорили, вся военка под кути сидит, и те, кто для госов пишет
Здравствуйте, CreatorCray, Вы писали:
vaa>>Кто-то пишет GUI (настольные приложения) на системных ЯП? CC>У меня есть свой UI FW написаный просто for fun на C++ + GDI.
А прослойка есть какая-нибудь, или прям GDI в коде пророс?
Я просто для рисования тоже GDI использую, но у меня свой интерфейс для рисования, который под винду реализован на GDI, и вся отрисовка идёт через этот интерфейс, что, теоретически, позволяет мне соскочить с винды на хоть тот же Qt, или прикрутить любой другой рисовальный бекэнд. У меня пока много рисования, но UI с кнопками и прочим барахлом тоже надо делать, вот думаю — либо самому всё делать, тогда зависимость от системы вообще минимальная будет, но будет много гемора, или сабклассить виндовые контролы и рисовать их через свой интерфейс. Я, признаться, начал уже уставать от этого велосипедостроения, хочется уже релиз выкатить.
ЗЫ Хотя, конечно, это прикольно было всё делать, но зело отдалило релиз. На Qt вышло бы гораздо быстрее, но я тоже предпочитаю принцип минимальной зависимости С другой стороны, релиза всё нет, хз, в другой раз наверное уже и не буду заморачиваться, возьму что-нибудь, чтоб побыстрее
Здравствуйте, пффф, Вы писали:
П>А прослойка есть какая-нибудь, или прям GDI в коде пророс?
Есессна
GDI там только для рендеринга финального результата, и то в основном TextOutW + BitBlt используется
Прога изначально писалась чтоб заменить собой excel spreadsheet, в котором перестало хватать функционала, так что там всё изначально было квадратно-гнездовое и очень много текста, потом ещё чутка непрямоугольной графики добавилось.
В принципе там другой rendering backend прицепить взамен не должно быть сильно сложно.
П>но UI с кнопками и прочим барахлом тоже надо делать
Именно что кнопка жеж делается вообще не приходя в сознание если не надо всякие анимации и прочий свистопердёж.
П>в другой раз наверное уже и не буду заморачиваться, возьму что-нибудь, чтоб побыстрее
В другой раз у тебя уже будет эта готовая либа.
У меня как раз "другой раз" вообще молниеносно написался, ибо практически всё было уже готово.
Здравствуйте, rudzuk, Вы писали:
п>> SVZ>TheBat — Delphi
п>> Да, забыл. Чуть ли не единственное известное мне массовое, написанное на дельфях
R>Что, и про TotalCommander не в курсе, и про ранний Skype?
Да, тоже забыл. Но тоталом не пользовался, а про скайп был не в курсе. Это всё? Или ещё что-то есть?
Здравствуйте, CreatorCray, Вы писали:
П>>но UI с кнопками и прочим барахлом тоже надо делать CC>Именно что кнопка жеж делается вообще не приходя в сознание если не надо всякие анимации и прочий свистопердёж.
Кнопка — это не просто кнопка, это ещё и фокус ввода и всё остальное. Ну и кнопка — да, это самое элементарное
П>>в другой раз наверное уже и не буду заморачиваться, возьму что-нибудь, чтоб побыстрее CC>В другой раз у тебя уже будет эта готовая либа.
А тут хз. Я уже писал аналогичное, но там был мега фреймворк с плагинами, своим IDL и библиотекаршами. Я его использовал в нескольких проектах, но он тяжеловат. Тут решил, что не хочу с ним возится. Хотя там и кросплатформа на линукс/фряху была, и рисовалка уже имела бэкэнды под Qt и wxWidgets. Запилил аналог заново, полегче. Ну, что-то стырил из старого, конечно. Вот тут и хз, может в очередной раз мне станет лень тащить и это. Потому что всегда чего-то не хватает в своём, и приходится допиливать. И получается, что продуктовый код пишется хорошо если половину времени, а половина уходит на свой фрейворк. А в стороннем — всё есть и не надо самому поддерживать
С другой стороны, релиза всё нет, хз, в другой раз наверное уже и не буду заморачиваться, возьму что-нибудь, чтоб побыстрее
