Комментарии 406
Вынужден констатировать, что
Прокачать профессиональные навыкиневозможно. Т.е. невозможно, если ты пытаешься сделать это до того, как начнешь этим зарабатывать. Всё дело в том, что «самоучители для чайников» не дают никакой прокачки, а осваивание по публикациям в интернете и документации длится слишком долго, и полученные таким образом навыки успевают устареть. Например, я пытался освоить программирование под Андроид в АндроидСтудии. Еще до того, как я разобрался, как следует правильно строить проект, вышло 3 (!!!) обновления SDK, и первый «блин комом» не захотел собираться под последним обновлением… Даже уследить за «обновлениями» терминологии сложно.
Т.е. даже не стоит пробовать самостоятельно грызть гранит IT наук?
Зависит от вида гранита.
К примеру, у меня тоже не сложилось по какой-то причине с AndroidStudio. Даже шаблонные и демо проекты не компилировались как надо… потратив много времени и версий, у меня все же получилось хоть что-то типовое, но логика работы Java в AndroidStudio меня поражала в самое сердце. Бросил.
Делаю приложения из HTML5+JS, обёрнутые в браузер (спасибо Intel XDK)
Вообще 1С (страшный сон, но в небольших городах — это самая распространенная вакансия программиста) звучит неплохо в плане самостоятельного обучения.
Тестировщики, опять же. Их берут довольно много, толковые люди там растут или в самом тестировании (автоматическое тестирование и составление автотестов), или в менеджмент или уходят в разработчики в той же конторе.
К примеру, у меня тоже не сложилось по какой-то причине с AndroidStudio. Даже шаблонные и демо проекты не компилировались как надо… потратив много времени и версий, у меня все же получилось хоть что-то типовое, но логика работы Java в AndroidStudio меня поражала в самое сердце. Бросил.
Делаю приложения из HTML5+JS, обёрнутые в браузер (спасибо Intel XDK)
Вообще 1С (страшный сон, но в небольших городах — это самая распространенная вакансия программиста) звучит неплохо в плане самостоятельного обучения.
Тестировщики, опять же. Их берут довольно много, толковые люди там растут или в самом тестировании (автоматическое тестирование и составление автотестов), или в менеджмент или уходят в разработчики в той же конторе.
IT-науки и промышленное программирование — немного разные вещи. Но пытаться осилить и то, и другое — нужно, если у Вас есть такая цель. Дерзайте, это очень интересно.
P.S Важный момент — если все-таки собираетесь за что-то браться, читайте прежде всего, официальную документацию, и очень внимательно.
пользование готовыми СДК и движками это не профессиональные навыки. 5-10 лет и инструменты меняются. Причем видим тенденцию, что разрабатывать всё становится проще.
Раньше ты учил ассемблер и С++, осваивал DirectX 7 api, а теперь любой школьник в пару кликов делает 3д игрули для андроида на готовых движках.
Т.е. нужно качать умение быстро учиться новым системам. Т.е. учиться учиться, а для этого надо качать абстрактное мышление, чтобы быстро видеть зависимости в глобальном плане, видеть общую картину, тогда материал быстрее усваивается. А также качать объем воображения, в котором можно больше и дольше удерживать алгоритмы и логику.
Раньше ты учил ассемблер и С++, осваивал DirectX 7 api, а теперь любой школьник в пару кликов делает 3д игрули для андроида на готовых движках.
Т.е. нужно качать умение быстро учиться новым системам. Т.е. учиться учиться, а для этого надо качать абстрактное мышление, чтобы быстро видеть зависимости в глобальном плане, видеть общую картину, тогда материал быстрее усваивается. А также качать объем воображения, в котором можно больше и дольше удерживать алгоритмы и логику.
Некоторые вещи устаревают долго. Реляционная алгебра, например. Многие языки долго держат обратную совместимость — изучите си, питон или пхп — через пять лет вы все ещё сможете ими пользоваться. Вообще чем фундаментальнее вещь, тем дольше ей можно пользоваться.
Я из тех самоучек, что еще помнят ассемблер x86 и знают, что такое «резидентная программа MS DOS». И Delphi мне знаком, и Си (и не плохо знакомы, смею надеяться)… И где сейчас эта Delphi? И где, кроме embedded devices, этот Си?
Невозможно чему-то учиться без задачи. То есть замкнутый круг: чтоб получить заработок, надо решить современную задачу. Чтобы решить современную задачу, надо знать современные «технологии» (будь то язык, фреймворк или что-то еще). Изучить современные технологии невозможно, т.к. их необъятно много и выбрать ту, которая поможет заработать, нельзя. Получается, мне не дадут работу, потому что я не знаю технологий, а технологии я не узнаю, пока не получу работу.
Всё, можно успокоиться и идти в охранники супермаркета.
Невозможно чему-то учиться без задачи. То есть замкнутый круг: чтоб получить заработок, надо решить современную задачу. Чтобы решить современную задачу, надо знать современные «технологии» (будь то язык, фреймворк или что-то еще). Изучить современные технологии невозможно, т.к. их необъятно много и выбрать ту, которая поможет заработать, нельзя. Получается, мне не дадут работу, потому что я не знаю технологий, а технологии я не узнаю, пока не получу работу.
Всё, можно успокоиться и идти в охранники супермаркета.
Если вам знакомы и Delphi и си — то все отлично. Delphi, правда, остался только в каком-нибудь корпоративном легаси, а с си все порядке. Сайты на нем не делают, а высоконагруженные веб-сервисы — очень даже. Драйвера и библиотеки тоже. Большой рынок, программистов много, зарплаты хорошие. Если вы ещё и структуры данных знаете (тоже не устарело), то вам пару месяцев прочитать/попробовать свежие библиотеки — и можно брать задачи джуниора (а там подтянитесь). Но, конечно, это все на ваше усмотрение. Охранники тоже иногда нужны, вам решать.
и сайты делают :)
Да я и на Delphi «сайт» делал, был грех. Работал в одной конторе, где директору забожалось каждый день иметь каждый день сводку о том, сколько какой цех электроэнергии, воды и газа израсходовал… Даные со счетчиков собирались и вносились в эксель, да только сам директор мог только одну кнопочку нажимать. Пришлось на дельфи накорябать прибамбас, который запускал экселевый файл со скриптом на VBA, скрипт этот формировал html-страничку, а прога на Дельфи это страничку вставляла во фрейм странички, которую сама генерировала… Этакий CGI-вариант динамической генерации сайта. Ну, оставалось мне только запустить этот дельфийский «сервер», и директор мог по кнопочке, которую ему нарисовали верстальщики в браузере, открывать «сайт со статистикой».
Тогда не было у нас ни серверов, ни апачей, нифига не было (как и знаний), потому так извращались…
Но все это ерунда — сейчас это никому не надо. А надо верстать сайты такими средствами, от одних названий которых меня дрожь пробирает. К тому моменту, когда я дочитаю простое описание возможностей этих средств, они устареют и станут не модными. Сколько сил было потрачено на «модный» ^parser — и где он, кому нужен?
Тогда не было у нас ни серверов, ни апачей, нифига не было (как и знаний), потому так извращались…
Но все это ерунда — сейчас это никому не надо. А надо верстать сайты такими средствами, от одних названий которых меня дрожь пробирает. К тому моменту, когда я дочитаю простое описание возможностей этих средств, они устареют и станут не модными. Сколько сил было потрачено на «модный» ^parser — и где он, кому нужен?
Да, были времена, когда VBA был в моде. Да и вместо JavaScript в html страничках бывало использовали VBScript. Это были лихие конец 90х — начало 00х. В те времена в одном из древних проектов делал выгрузку товаров в интернет магазин запуском шельника, который выполнял VBA скрипт документа с обновлённым прайсом. И на страничке использовался XMLHttpRequest для подгрузки данных в разворачивающихся спойлерах (тогда ещё слова AJAX не было в обороте).
По поводу parser, тоже приходилось несколько лет поддерживать сайт серверная часть которого была разработана на нём. Это был ад. Документация не всегда соответствовала действительности, приходилось частенько заглядывать в исходные коды той сборки парсера, которая использовалась на продакшне.
А вообще я хотел сказать про то, что нужно уметь заранее увидеть ту технологию, которая в будущем выстрелит, разобраться в ней, а когда придёт время, то быть уже специалистом в данной теме. И мне кажется, что одна из таких технологий — это WebAssembly. Т.е. уже сейчас можно разрабатывать и компилировать с различных языков программирования нативные приложения и исполнять их в браузере. Вот тут я перечислял несколько ЯП, на которых уже можно делать подобное: toster.ru/q/454806
По поводу parser, тоже приходилось несколько лет поддерживать сайт серверная часть которого была разработана на нём. Это был ад. Документация не всегда соответствовала действительности, приходилось частенько заглядывать в исходные коды той сборки парсера, которая использовалась на продакшне.
А вообще я хотел сказать про то, что нужно уметь заранее увидеть ту технологию, которая в будущем выстрелит, разобраться в ней, а когда придёт время, то быть уже специалистом в данной теме. И мне кажется, что одна из таких технологий — это WebAssembly. Т.е. уже сейчас можно разрабатывать и компилировать с различных языков программирования нативные приложения и исполнять их в браузере. Вот тут я перечислял несколько ЯП, на которых уже можно делать подобное: toster.ru/q/454806
Чем (технологически) WebAssembly отличается от Java-аплетов, которые вымерли чуть менее чем полностью?
А ещё wasm файлы можно кешировать на всяких CDN-ах, да и в localStorage-ах и IndexedDB, версионировать и подтягивать только те wasm-ы, которые требуют обновления. Т.е. веб приложение может состоять из нескольких wasm-ов, которые можно подгружать по мере необходимости, тем самым можно сократить начальную загрузку веб-страницы.
А ещё, думаю, было бы разумно встроить в браузеры какое-то общее хранилище для wasm-модулей, чтобы одни и те же wasm-модули не грузить повторно для разных веб-приложений. Некий стандартный набор wasm-библиотек.
Вы так говорите, как будто Java-аплеты нельзя было кэшировать, версионировать и подтягивать динамически. Но что-то пошло не так…
C используется не для верстки, а для CMS.
Delphi жив, да, много легаси, но новые проекты тоже есть. Дельфисты, шарящие в web очень ценятся.
И где, кроме embedded devices, этот Си?
Ну например, python написан на Си, и плагины к нему тоже пишутся на Си.
Ну и Linux тоже рука не поднимется назвать «кодом для embedded devices».
Глянул, где у меня в квартире liux… 3 андроида, роутер… То, что делаем по работе на linux — тоже для embeded… В метро заходишь — инфотерминал на linux… Ну в общем не так уж и далеко от истины — linux в embeded сильно прижился.
Linux повсюду: и в embedded, и на десктопах, и на серверах.
И OSX туда же: не совсем Linux, но тоже на Си.
Пять лет назад я собеседовался было в Facebook (уж казалось бы, что может быть дальше от мира embedded?), и между прочим спросил собеседователя, не пригодятся ли у них мои сишные скиллы.
"--Ещё как! У нас даже есть команда, которая пишет кастомные линуховые драйвера для сетевух на наших серверах, чтобы выжать из них максимум производительности."
И OSX туда же: не совсем Linux, но тоже на Си.
Пять лет назад я собеседовался было в Facebook (уж казалось бы, что может быть дальше от мира embedded?), и между прочим спросил собеседователя, не пригодятся ли у них мои сишные скиллы.
"--Ещё как! У нас даже есть команда, которая пишет кастомные линуховые драйвера для сетевух на наших серверах, чтобы выжать из них максимум производительности."
На дескотопах — очень мало где. А сервер — не так далек от embeded. То есть тоже железка без монитора и клавиатуры.
На серверах есть альтернатива в виде FreeBSD, но она тоже сишная. А в embede — альтернативы почти нет. Слишком уж хорошо линукс адаптируется к разным архитектурам.
То есть единственная серьезная альтернатива — это вообще без нормальной ОС, с FreeRTOS, например (тоже на Си). Мегабайт ПЗУ, полмега ОЗУ — это не для linux. Зато плата сильно проще. Но это уже deep embeded.
На серверах есть альтернатива в виде FreeBSD, но она тоже сишная. А в embede — альтернативы почти нет. Слишком уж хорошо линукс адаптируется к разным архитектурам.
То есть единственная серьезная альтернатива — это вообще без нормальной ОС, с FreeRTOS, например (тоже на Си). Мегабайт ПЗУ, полмега ОЗУ — это не для linux. Зато плата сильно проще. Но это уже deep embeded.
Не хочу углубляться в вопросы терминологии, но если deep embedded — это «Мегабайт ПЗУ, полмега ОЗУ», то как вы назовёте micro:bit c 256КБ Flash и 16КБ ОЗУ?
Туда даже FreeRTOS вряд ли влез бы; поэтому под неё пишут на голом Си прямо без ОС :-)
Туда даже FreeRTOS вряд ли влез бы; поэтому под неё пишут на голом Си прямо без ОС :-)
FreeRTOS влезет в такое. У нас примерно такой SOC в качестве мультиплексора использовался. Писали на Си с примесью С++. Самый deep — это PIC, там иногда сотни байт ОЗУ бывает. ну и AVR, конечно.
А по терминологии — если мы не используем внешнего ОЗУ и ПЗУ и вмещаемся в ресурсы SOC — это более-менее deep. я STM32F7 имел ввиду.
А по терминологии — если мы не используем внешнего ОЗУ и ПЗУ и вмещаемся в ресурсы SOC — это более-менее deep. я STM32F7 имел ввиду.
Ну например skype написан на delphi. В области АСУТП дельфи очень хорошая альтернатива С++ — больше надежность, короче (и прогнозируемей) сроки.
Ст — очень много где. Да, с легкой примесью С++, но это Си. Как пример без примеси — ядро linux и очень много линуксовского софта.
Хотите программировать на Андроиды и айфоны? Да нет проблем. Берете последний дельфи — и вперед.
Тут другой вопрос важен. Если вы не читали Рэя Конопко — вряд ли вас возьмут писать на дельфи. Если вы не можете эмулировать классы на Си — вряд ли вас возьмут писать на Си. Это я к тому, что нужны как минимум мидлы, а не юниоры.
Ст — очень много где. Да, с легкой примесью С++, но это Си. Как пример без примеси — ядро linux и очень много линуксовского софта.
Хотите программировать на Андроиды и айфоны? Да нет проблем. Берете последний дельфи — и вперед.
Тут другой вопрос важен. Если вы не читали Рэя Конопко — вряд ли вас возьмут писать на дельфи. Если вы не можете эмулировать классы на Си — вряд ли вас возьмут писать на Си. Это я к тому, что нужны как минимум мидлы, а не юниоры.
Да лично для своих целей я пишу и на Delphi, и на Си. Просто это явно не тренд, и, хотя есть иной раз шанс что-то этим заработать, его все меньше и меньше. По поводу Конопко — это, слава богу, я освоил давным-давно, когда еще не так отстал от линии тренда. И уж во всяком случае Form13.Button22 в моих проектах нет так же много-много лет. Только сути моего высказывания это не меняет: я никогда уже не смогу изучить то, что нужно именно сейчас, потому как к моменту завершения изучения оно станет не нужным. А получить работу, чтобы изучать по ходу работы, я не смогу, т.к. никого не волнует процесс обучения, всем нужен работник.
Про эмулирование классов на Си вообще не понял…
Про эмулирование классов на Си вообще не понял…
> А получить работу, чтобы изучать по ходу работы, я не смогу, т.к. никого не волнует процесс обучения, всем нужен работник.
А вы прикиньтесь зелёным джуном. Впрочем, с возрастом соглашаться на позицию джуна будет сложнее, не спорю. Да и работодатель будет предвзято относиться.
> Про эмулирование классов на Си вообще не понял…
Ну вот, например, у вас есть C++ код и вы хотите его оформить в виде динамической библиотеки, но в С-интерфейсом. Что будете делать?
А вы прикиньтесь зелёным джуном. Впрочем, с возрастом соглашаться на позицию джуна будет сложнее, не спорю. Да и работодатель будет предвзято относиться.
> Про эмулирование классов на Си вообще не понял…
Ну вот, например, у вас есть C++ код и вы хотите его оформить в виде динамической библиотеки, но в С-интерфейсом. Что будете делать?
Сеньора переучить на другой язык намного проще, чем вырастить сенора из джуниора. Сеньор — он на то и сеньор, что не так сильно зависит от языка.
Ну вот, например, у вас есть C++ код и вы хотите его оформить в виде динамической библиотеки, но в С-интерфейсом. Что будете делать?Ну, я бы сделал так:
1. конструкторы и деструкторы необходимых классов разместил бы в соответствующих ветках DLLmain (загрузка и выгрузка соответственно)
2. все публичные методы этих классов вынес бы при помощи функций-оберток в экспортные функции DLL
3. соответственно все эти функции-обертки, структуры данных и константы, необходимые им, описал бы в заголовочнике.
Так?
Что именно? Статические экземпляры классов должны быть инициализированы до момента первого обращения к их методам? Где же, кроме как в DLLmain это делать? Ну и почистить память тоже при выгрузке DLL — где?
Статические экземпляры классов должны быть инициализированы до момента первого обращения к их методам?
CRT сама создаст и разрушит все статические объекты C++.
Вот если вы пишете на чистом C или на C++, но с выделением памяти через malloc/free, либо с использованием обычных указателей вместо умных, тогда да, нужно всё это делать вручную.
- все публичные методы этих классов вынес бы при помощи функций-оберток в экспортные функции DLL
- соответственно все эти функции-обертки, структуры данных и константы, необходимые им, описал бы в заголовочнике.
Да, примерно так.
Быстро меняющиеся технологии — это однодневки, их вообще не стоит учить. Из того, что видимо стоит — С++, java, питон, С#, rust.
Вполне можно иметь классы на Си. Более того, можно на Си сделать и полиморфизм. Делается структура и набор методов с первым параметром — указателем на структуру. Для полиморфизма — можно и свои VMT завести.
А вообще-то нормальному программисту не очень важно, на каком языке писать. Язык — это дело наживное, умение писать важнее.
Вполне можно иметь классы на Си. Более того, можно на Си сделать и полиморфизм. Делается структура и набор методов с первым параметром — указателем на структуру. Для полиморфизма — можно и свои VMT завести.
А вообще-то нормальному программисту не очень важно, на каком языке писать. Язык — это дело наживное, умение писать важнее.
А вообще-то нормальному программисту не очень важно, на каком языке писать. Язык — это дело наживное, умение писать важнее.
Но это может зависеть от класса языка, скажем так. Я, в принципе, и на питоне писать смогу, если жизнь заставит, но наиболее эффективен (и счастлив) я буду на чём-нибудь сильно статически типизированном, с тайпчекером и прочими прелестями. Мозги у меня так работают уж.
А вообще-то нормальному программисту не очень важно, на каком языке писать. Язык — это дело наживное, умение писать важнееОй, не скажите! Вроде как я тоже так думал всю сознательную жизнь, но сегодня при слове «функциональное программирвание» или «лямбда-выражения» я встаю в ступор и просто не понимаю, что это и нафиг нужно. Сама концепция вышла из поля моего зрения… И, соответственно, написать в этом ключе я уже не смогу ничего.
А вы не вставайте в ступор, а просто пишите. Не нужно насиловать мозг Хаскелем, просто пишите код на языках с элементами функционального программирования. Хороший пример — Linq из C#, можно попробовать и на C++, но синкасис лямбд C++ довольно многословен.
Вот пример кода на C# из моего проекта
var v1 = data.Removed.Where(x => x.Type == AttributeType.Parameter)
.Select(x => new KeyValuePair<string, string>(x.Name, string.Empty));
var v2 = data.Replaced.Concat(data.Modified).Where(x => x.Key.Type == AttributeType.Parameter)
.Select(x => new KeyValuePair<string, string>(x.Key.Name, x.Value.Value ?? string.Empty));
return v1.Concat(v2).OrderBy(x => x.Key);Аналогичный код в процедурном стиле занял бы в 3 раза больше строк.
Код занял бы в 3 раза больше строк, но был бы в 9 раз понятнее. Извините, но я из тех «программистов», которые придерживаются правила «ставь скобки, невзирая на приоритеты операций, чтобы однозначность выражения была понятна абсолютно всем, даже непрограммистам», так что стремление делать код короче, но загадочнее мне абсолютно не понятно.
Пример из C++:
std::sort(s.begin(), s.end(), [](SomeType a, SomeType b) {
return b.field1 < a.field1;
});и
struct {
bool operator()(SomeType a, SomeType b) const
{
return b.field1 < a.field1;
}
} customLess;
std::sort(s.begin(), s.end(), customLess);В первом варианте не только гораздо меньше строк, так он все-таки ощутимо понятнее и приятнее выглядит. Особенно если таких операций не одна, а несколько десятков.
Точно также в коде на C#/LINQ приведенном комментатором выше, при разложении лямбд на отдельные вызываемые функции (их там по одной на каждую строку, аж 5 штук, и это еще лайт-вариант) код стал бы не в 9 раз понятнее, а в 9 раз запутаннее, и разобраться "что к чему относится и что за чем стоит" было бы ощутимо сложнее.
Не в коня корм, я оба варианта не понял…
Можно пойти дальше и разворачивать каждый вызов Where, Select и т.д. в код, как это делалось раньше, с использованием `for`.
Еще адовее выходит, да.
Вместо
var v1 = data.Removed.Where(x => x.Type == AttributeType.Parameter)писать
bool SomeTypeFilter(SomeType x)
{
return (x.Type == AttributeType.Parameter);
}
var v1 = new List<Something>();
for (int i = 0; i < data.Removed.Length; i++)
{
if (SomeTypeFilter(data.Removed[i]))
v1.Add(data.Removed[i]);
}и это еще без поддержки lazy evaluations
Не нужно насиловать мозг Хаскелем
Есть и обратная точка зрения: нужно изнасиловать мозг хаскелем, чтобы в полной мере, так сказать, прочувствовать идеи ФП.
Создать лямбду, чтобы передать её в std::sort — одно дело. Создать лямбду, чтобы вернуть её как результат некоторой функции, который потом можно вызывать, и так удобнее реализовать некоторую часть алгоритма — другой. Ну, понимание, что функции — это действительно first-class citizens, оно полезное, но оно приходит через небольшой мозговыверт.
Понять, что такое катаморфизмы-анаморфизмы свёртки-развёртки и потом рассуждать в их терминах тоже полезно для большей декомпозиции алгоритмов на этаком микроуровне.
Писать обобщённый код через тайпклассы полезно, чтобы явно выделять и изолировать требования к передаваемым типам (а скоро таки и в плюсах концепты уже будут).
> Есть и обратная точка зрения: нужно изнасиловать мозг хаскелем, чтобы в полной мере, так сказать, прочувствовать идеи ФП.
Мозг имеет смысл насиловать только в случае, если это будет применяться для решения какой-нибудь практической задачи. А какие практические задачи можно решить с помощью Хаскеля?
> Создать лямбду, чтобы вернуть её как результат некоторой функции, который потом можно вызывать, и так удобнее реализовать некоторую часть алгоритма — другой.
За всё время делал так всего пару раз, для генерации Expression Tree в рантайме. В большинстве же случаев, когда такое возникает, и понятнее, и проще реализовать такой функционал с помощью интерфейсов.
Мозг имеет смысл насиловать только в случае, если это будет применяться для решения какой-нибудь практической задачи. А какие практические задачи можно решить с помощью Хаскеля?
> Создать лямбду, чтобы вернуть её как результат некоторой функции, который потом можно вызывать, и так удобнее реализовать некоторую часть алгоритма — другой.
За всё время делал так всего пару раз, для генерации Expression Tree в рантайме. В большинстве же случаев, когда такое возникает, и понятнее, и проще реализовать такой функционал с помощью интерфейсов.
Мозг имеет смысл насиловать только в случае, если это будет применяться для решения какой-нибудь практической задачи.
Не только. Мозг имеет смысл насиловать ради того, чтобы познакомиться с большим набором концепций, прокачать соответствующее мышление и так далее. Ну, тяжело в учении, легко в бою.
Сложно сформулировать это в паре-тройке предложений, но после знакомства с хаскелем я стал писать субъективно более хороший код и на плюсах.
А какие практические задачи можно решить с помощью Хаскеля?
Ну, на нём таки не только факториалы считать можно. Можно компиляторы писать, можно всякие парсеры-анализаторы логов, можно перекладывалки из одной БД в другую, можно веб-сервисы, можно eDSL для типобезопасного программирования эмбеддщины, много чего можно. Какие-то наркоманы на нём даже ОС пытались писать, но оно умерло лет 10 назад, к сожалению.
За всё время делал так всего пару раз, для генерации Expression Tree в рантайме. В большинстве же случаев, когда такое возникает, и понятнее, и проще реализовать такой функционал с помощью интерфейсов.
Безусловно. Но, с одной стороны, с таким подходом имеет смысл таки быть знакомым (он вот и вам пригодился). С другой — просто в выбранном вами языке подход с интерфейсом оказывается проще и понятнее.
А интерфейсы, как известно — частный случай тайпклассов. Но это уж так.
Лямбды были ещё в ALGOL-60 под названием "передача параметров по наименованию". Поищите «Трюк Йенсена» Смысл в том, что при передаче в качестве параметрах X+Y по наименованию, каждый раз при обращении к параметру считается X+Y. А если мы в функции меняем X или Y — то и получим каждый раз разный результат вычисления X+Y.
Лямбды заменяют вложенные процедуры в языках, где их нет. Работаю как синтаксический сахар и как источник для трюков и багов.
Функциональное программирование — это LISP, FORTH и программируемые микрокалькуляторы из детства. Вспомнили калькулятор? Там нельзя было программировать процедурно — только функционально. Вот и в некоторых языках — только функциональное программирование.
Грубо говоря, это иной способ мышления. Если к нему привык — то удобно. если не привык — полгода не переучивание мозгов.
На современном дельфи можно писать лямбды. А функционально программировать — можно было ещё на паскале. Просто неудобно — инфраструктуры нет.
Лямбды заменяют вложенные процедуры в языках, где их нет. Работаю как синтаксический сахар и как источник для трюков и багов.
Функциональное программирование — это LISP, FORTH и программируемые микрокалькуляторы из детства. Вспомнили калькулятор? Там нельзя было программировать процедурно — только функционально. Вот и в некоторых языках — только функциональное программирование.
Грубо говоря, это иной способ мышления. Если к нему привык — то удобно. если не привык — полгода не переучивание мозгов.
На современном дельфи можно писать лямбды. А функционально программировать — можно было ещё на паскале. Просто неудобно — инфраструктуры нет.
Функциональщина в стиле LISP и функциональщина в стиле семейства ML-языков — это два разных лагеря.
Но всё-таки неплохо, когда язык даёт инфраструктуру и средства для функционального программирования. Так-то в функциональном стиле писать можно и на паскале, и на плюсах, и даже на С, наверное, но очень сложно.
Почитайте парсер любого языка программирования, написанный рекурсивным спуском. Увидите, что не так уж и сложно явно функциональный алгоритм записать на любом языке.
Я, если честно, не вижу в канонических реализациях рекурсивного спуска (по крайней мере, в тех, что я видел) ничего функционального. Императивно-процедурное вижу, но не функциональное.
Возможно, это для вас вопрос терминов — тогда нет смысла спорить. Процедурное отображение на Си — эквивалентно функциональному стилю, а это главное.
Ну, процедурное программирование таки не равно функциональному программированию, это два разных термина.
Совсем хардкорно-функциональный подход к парсингу, кстати — это, например, для регулярок и для контекстно-свободных языков. Но это так, побаловаться.
у Skype на Delphi был написан только UI, да и то в очень-очень древние времена. Сейчас уже давно там Delphi нет.
Про «программировать под андроиды и айфоны без проблем» — увы, не «без проблем». Пару лет назад даже UI простейших приложений работал весьма медленно и нестабильно, сейчас, возможно, ситуация исправилась, но сама по себе концепция «брать немаленькие деньги за весьма посредственную среду разработки» (у Starter-версии нет даже автодополнения, Карл!), когда есть отличные по качеству бесплатно распространяемые альтернативы — имхо, проигрышная.
А в области АСУТП (где я крутился не год и не два) большая часть с Delphi на C# переехала (к вопросу о надежности и прогнозируемости сроков). Да и просто, достаточно на любом сайте с вакансиями вбить в поиск названия соответствующих технологий и сравнить количество вакансий, отфильтровав из них приличные (не рассматривая поддержку древних легаси-проектов и олдфажные заводы).
Про «программировать под андроиды и айфоны без проблем» — увы, не «без проблем». Пару лет назад даже UI простейших приложений работал весьма медленно и нестабильно, сейчас, возможно, ситуация исправилась, но сама по себе концепция «брать немаленькие деньги за весьма посредственную среду разработки» (у Starter-версии нет даже автодополнения, Карл!), когда есть отличные по качеству бесплатно распространяемые альтернативы — имхо, проигрышная.
А в области АСУТП (где я крутился не год и не два) большая часть с Delphi на C# переехала (к вопросу о надежности и прогнозируемости сроков). Да и просто, достаточно на любом сайте с вакансиями вбить в поиск названия соответствующих технологий и сравнить количество вакансий, отфильтровав из них приличные (не рассматривая поддержку древних легаси-проектов и олдфажные заводы).
Вообще-то назначение там другое — сделать одно приложение и иметь его и на десктопе под Windows и на мобильниках. Тем самым выиграв пару миллионов на разработку отдельного мобильного приложения. Собственно всегда коньком дельфи была быстрая разработка прототипа. А чем вы его заменит хотите? Где ещё настолько же высокая скорость разработки прототипа GUI-приложений?
Xamarin/C#. Тоже не без недостатков, но весьма активно развивающийся и главное, с большим коммьюнити. И среда разработки/SDK полностью бесплатные.
Что там с визуальным конструированием? Глянул пример из вики — похоже, что его нет?
Что касается цены… Месячный ФОП разработчика — это не те деньги, которые важны для фирмы.
Что касается цены… Месячный ФОП разработчика — это не те деньги, которые важны для фирмы.
Все есть. Для Android и iOS «из коробки», для .Forms — либо Gorilla Player, либо UI Sleuth (демо тут vimeo.com/user60270369) — у последнего так кроме визуального конструирования вообще крутые вещи есть, типа возможности заполнять данные в виджетах UI удаленно в запущенном приложении. Открытый код, свободная лицензия :)
Проблема не в цене с привязкой к зарплатам разработчиков. Запуская новый проект (если только это не калькулятор для дипломной работы студента) нужно кроме «удобства технологии» задумываться еще о том, где взять разработчиков под эту технологию. И где взять новых разработчиков для поддержки, если проект будет разрастаться или старички рано или поздно уйдут. И каково будет разработчикам при необходимости получения поддержки.
Тут можно бросить беглый взгляд на сообщество: по тегу c# на stackoverflow более 1 миллиона результатов, по тегу delphi — 64 тысячи. То же самое с состоянием на рынке труда: C# — 28 тысяч вакансий на indeed, Delphi 2 тысячи вакансий.
И даже если какой-нибудь молодой начинающий разработчик по наивности поведется на призывы вида «быстрая разработка, переносимость, и т.д.» и захочет освоить стек Embarcadero, чтобы с этим багажом выйти на рынок труда — то все, провал. Либо плати деньги, либо мучайся со Starter-версиями, которые ограничены настолько, что пытаться работать с ними есть настоящее мучение. При том что у альтернатив бесплатные средства разработки, прекрасная документация и огромное сообщество.
Проблема не в цене с привязкой к зарплатам разработчиков. Запуская новый проект (если только это не калькулятор для дипломной работы студента) нужно кроме «удобства технологии» задумываться еще о том, где взять разработчиков под эту технологию. И где взять новых разработчиков для поддержки, если проект будет разрастаться или старички рано или поздно уйдут. И каково будет разработчикам при необходимости получения поддержки.
Тут можно бросить беглый взгляд на сообщество: по тегу c# на stackoverflow более 1 миллиона результатов, по тегу delphi — 64 тысячи. То же самое с состоянием на рынке труда: C# — 28 тысяч вакансий на indeed, Delphi 2 тысячи вакансий.
И даже если какой-нибудь молодой начинающий разработчик по наивности поведется на призывы вида «быстрая разработка, переносимость, и т.д.» и захочет освоить стек Embarcadero, чтобы с этим багажом выйти на рынок труда — то все, провал. Либо плати деньги, либо мучайся со Starter-версиями, которые ограничены настолько, что пытаться работать с ними есть настоящее мучение. При том что у альтернатив бесплатные средства разработки, прекрасная документация и огромное сообщество.
То есть никакого единого визуального редактора нет? И для каждой платформы делать свою морду?
Количество вопросов — палка о двух концах. По дельфи у меня никогда не было желания что-то спрашивать — все и так очевидно. Поэтому миллион вопросов очень настораживает. Значит документация на технологию плохая, а сама технология — запутанная. Зато очень много вопросов по JS.
Непонятно, с чего вы это взяли. Если бы вы были правы — никто не пользовался бы word. Потому что «либо плати деньги, либо мучайся со WordPad».
Количество вопросов — палка о двух концах. По дельфи у меня никогда не было желания что-то спрашивать — все и так очевидно. Поэтому миллион вопросов очень настораживает. Значит документация на технологию плохая, а сама технология — запутанная. Зато очень много вопросов по JS.
Баян про запутанность JS
Либо плати деньги, либо мучайся со Starter-версиями
Непонятно, с чего вы это взяли. Если бы вы были правы — никто не пользовался бы word. Потому что «либо плати деньги, либо мучайся со WordPad».
Gorilla и UI Sleuth это именно единый для всех платформ подход.
Если нужны только конкретные таргеты — то есть более удобные и подходящие инструменты, гораздо более близкие к нативным контролам.
Если вас смущает оценка активности коммьюнити по вопросам и ответам, то можно поглядеть на github: madnight.github.io/githut
Delphi/ObjectPascal в статистику вообще не попадают из-за крайне низкой популярности
Со своего опыта. Качал Starter-версии Delphi и C++ Builder (релиз Berlin), так там даже ничего похожего на IntelliSense не было, не говоря уж о рефакторинг (о чем кстати и написано в Release Notes про ограничения Starter-версий). Иначе как издевательством это назвать нельзя :)
Если нужны только конкретные таргеты — то есть более удобные и подходящие инструменты, гораздо более близкие к нативным контролам.
Если вас смущает оценка активности коммьюнити по вопросам и ответам, то можно поглядеть на github: madnight.github.io/githut
Delphi/ObjectPascal в статистику вообще не попадают из-за крайне низкой популярности
Непонятно, с чего вы это взяли
Со своего опыта. Качал Starter-версии Delphi и C++ Builder (релиз Berlin), так там даже ничего похожего на IntelliSense не было, не говоря уж о рефакторинг (о чем кстати и написано в Release Notes про ограничения Starter-версий). Иначе как издевательством это назвать нельзя :)
Delphi/ObjectPascal в статистику вообще не попадают из-за крайне низкой популярности
Не вижу там, например, Visual Studio. Значит на нём уже не пишут?Delphi (как инструмент разработки) — это ещё и С++ и С#.
Со своего опыта.
Странный у вас опыт. Вы считаете что если вы хотите освоить контролеры Sematic, то должны дома иметь личный контроллер?
Знаете, в моей юности час работы на компе был равен недельной зарплате. Так что думать и писать программы за компом было нельзя. Писали на бумажке, а за компом — лишь отлаживались. И ничего, изучению языков и инструментов это не мешало.
Не вижу там, например, Visual Studio.
Не хочу вас расстраивать, но Visual Studio — это не язык программирования и не фреймворк. Это IDE, и в списке языков программирования ей делать нечего.
Delphi (как инструмент разработки) — это ещё и С++ и С#.
Это на какой планете? :)
В Embarcadero Delphi нет поддержки C++. Она есть в C++ Builder и RAD Studio.
И уж тем более там в принципе ни в одном продукте нет поддержки C#.
Вы считаете что если вы хотите освоить контролеры Sematic, то должны дома иметь личный контроллер?
Вы передергиваете примеры. Чтобы освоить контроллеры Simatic, мне как минимум будет нужна среда разработки с эмулятором.
Собственно, про среду разработки мы речь и ведем.
Писали на бумажке, а за компом — лишь отлаживались. И ничего, изучению языков и инструментов это не мешало.
Времена меняются, и Вы, к тому же, сами себе противоречите. Выше вы агитируете за «быструю разработку прототипов», а теперь за «написание на бумажке и отладку на компьютере». Время — деньги, не только для профессиональных разработчиков, но и для только начинающих обучаться всей этой магии. Зачем тратить N времени на изучение основ, когда у конкурирующей и гораздо более распространенной и востребованной технологии это можно изучить за N/3 времени и развиваться дальше?
И уж тем более там в принципе ни в одном продукте нет поддержки C#.
Что, правда? Думаете то, что было, 10 лет назад — оно на другой планете было? Ну тогда почитайте
Delphi 2006 (Delphi 10, Borland Developer Studio 4.0) Была выпущена в декабре 2005 года. В одной IDE поддерживалась разработка проектов C#, Delphi.NET, Delphi Win32 и C++.Заодно — почитайте про Delphi for .NET и Delphi Prism.
Visual Studio — это не язык программирования и не фреймворк.
Ровно так же и язык изначально звался Obkect Pascal, а Delphi — это всего лишь IDE. Потом маркетологи все смешали.
Чтобы освоить контроллеры Simatic, мне как минимум будет нужна среда разработки с эмулятором.
Ну что я могу сказать — сочувствую. Бывают слепые программисты, а бывают вот такие как вы — кинестетики, которым все нужно обязательно потрогать руками. Просто поймите, что вы — исключение, а в основном программисты — это визуалы. И им для изучения нужна лишь документация.
Зачем тратить N времени на изучение основ, когда у конкурирующей и гораздо более распространенной и востребованной технологии это можно изучить за N/3 времени и развиваться дальше?
Да затем, что нахватавшись верхов, вы не понимаете основы.Поэтому и скорость у вас низкая. Чтобы изучить новый язык вам сколько нужно времени? Мне по учебнику — месяц. А сколько вы будете мучаться вашим методом тыка?
Поэтому я могу позволить себе изучать технологии под задачу прямо на рабочем месте, а вы ищите себе рабочее место под изученные технологии.
Что, правда? Думаете то, что было, 10 лет назад — оно на другой планете было?
Я знал, что вы сошлетесь на древние версии :) Только вот мы про настоящее время говорим, а не про то что 10 лет назад было.
Ровно так же и язык изначально звался Obkect Pascal, а Delphi — это всего лишь IDE
И что из этого следует? Object Pascal тоже в актуальном списке нет, есть только в прошлых годах на последних местах.
им для изучения нужна лишь документация.
Теория без практики не стоит ничего. Особенно в коммерческой разработке ПО.
Как раз из-за самоуверенных, но «зеленых» разработчиков с подходом «я тут немного почитал и готов делать все что угодно», в случае, если у них не будет твердого и внимательного ментора и механизма ревью, в проектах и получается говнокод, увы.
Чтобы изучить новый язык вам сколько нужно времени? Мне по учебнику — месяц. А сколько вы будете мучаться вашим методом тыка?
Попробуйте придти на собеседование на работу в _приличную_ фирму на любую позицию старше Junior'а и сказать про ключевой стек проекта «я вообще никогда ничего подобного не делал и знаю только теорию, но буду изучить технологию под задачу прямо на рабочем месте» и посмотрите на результат.
Чтобы изучить новый язык вам сколько нужно времени? Мне по учебнику — месяц. А сколько вы будете мучаться вашим методом тыка?
А причем здесь метод тыка? Вы можете держать в голове тысячи методов стандартных библиотек и API платформы с точности до каждого символа, порядка и типов аргументов с учетом всех перегрузок функций? Если да, то вы гений, не тратьте свое время на хабр, вас ждут великие дела. Если нет, то при использовании предлагаемых вами инструментов, вам придется каждый раз при каких-либо сомнениях или ошибки компиляции производить поиск по справочникам. Вот она и разница в скорости разработки.
И что из этого следует? Object Pascal тоже в актуальном списке нет,
И что? Вы можете написать тот тезис, который защищаете? Есть языки, на которых принято выкладывать на гитхаб, а есть — на которых нет. JEDI, например, вовсе не на гитхабе хостится.
Не вижу там ada, хотя на ней огромная куча военных проектов и авионики пишется.
Если грубо — то, что международный язык английский, не означает, что на русском не говорят. Хотите получить популярность на гитхабе — пишите на С и С++.
Как раз из-за самоуверенных, но «зеленых» разработчиков с подходом «я тут немного почитал и готов делать все что угодно»
Угу. Именно что немного почитал, кое-что поделал руками — и получил говнокод. А если читать учебники и «от корки до корки» делать задания — код получается вполне нормальный.
Попробуйте придти на собеседование на работу в _приличную_ фирму
А зачем? я на собеседования ходил один раз в жизни, в 17 лет. С тех пор — переманивали. И мы сейчас переманиваем со словами «не важно, что ты не знаешь GPS, как раз этому мы тебя научим».
Вот она и разница в скорости разработки.
Один раз потратите неделю на поиски ошибки — начнете каждый раз проверять по API. Нужно помнить, что в принципе умеет библиотека. А подробности вызовов — обязательно нужно проверять.Собственно в нормальном IDE это не сложно — можно мышкой навести и прочитать описание параметров.
Собственно скорость разработки — это вовсе не скорость написания кода, это скорость отладки. И выигрывает тот, кто пишет медленно, зато не тратит времени на отладку.
В голове я держу не так много — 100-200 тысяч строк. Так что предпочитаю это место потратить на код текущего проекта.
А зачем? я на собеседования ходил один раз в жизни, в 17 лет. С тех пор — переманивали.
Не подскажете, как «переманивабельность» в себе развить? Вы ж сами наверняка что-то для этого делали? Кто-то же о вас узнавал в конце концов. А то кодишь 100500 лет с ощущением «нафиг я кому тут еще сдался, таких гавриков тут и без меня 100500».
Мой опыт показывает, что достаточно профиля в LinkedIn (в него стоит добавить актуальную информацию и добавлять в друзья коллег на каждом месте работы), чтобы пару раз в месяц стучались рекрутеры. Другой вопрос, что что-то интересное они могут предложить раз в год, не чаще.
Хотя если менять работу раз в год-два для вас нормально, то пойдёт.
Хотя если менять работу раз в год-два для вас нормально, то пойдёт.
Думаю, что нормально менять работу раз в 3 — 4 года, но рекрутеры предлагают такую зелёную тоску, от которой хочется выть волком и проработать на родной фирме еще 3 — 4 года.
Никогда не чувствовал себя одним из 100500. Наоборот — «Быть как все? А зааачем?!» Так что не вижу смысла быть винтиком. Всегда можно взять себе отдельный кусок проекта (или функциональности) и стать в нем гуру. Отличная работа (на 6 по пятибальной) всего лишь 20-30 процентов затратнее работы на троечку. А дальше — "никогда ничего не просите, все придут и сами дадут". Ну и понимание, что не на помойке родился, оно тоже важно.
Так что ничего существенного, увы, сказать не могу. Скорее это вопрос о выборе профессии, то есть, а в какой профессии я могу состояться? Каким делом я стал бы заниматься бесплатно? Если профессия выбрана верно — так и переманивать будут.
Так что ничего существенного, увы, сказать не могу. Скорее это вопрос о выборе профессии, то есть, а в какой профессии я могу состояться? Каким делом я стал бы заниматься бесплатно? Если профессия выбрана верно — так и переманивать будут.
Да я ударник каптруда, перевыполняю план, самый квалифицированный в конторе, но типичный, как в ветке «4 типажа программистов» определено, линейщик. И контора мне дала всё, что могла. И трудно себе признаться в 44 года, что ты неправильно выбрал профессию. И почти невозможно «уйти в никуда» из оплачиваемой нормально профессии.
Уйти в любой момент можно. Бабушкина сестра в 70 лет ушла из разработчиков АСУТП (на релейной технике) в вахтеры в ДК. Собственно ушла потому, что настал переход на микроконтроллеры, а это в 70 лет тяжеловато. Ничего, через 2 года стала в этом же ДК главным администратором. Ходила бесплатно по всем театрам, куча артистов в личных друзьях и была счастлива.
Грубо говоря, если у вас нету десятка профессий (не бумажек, а профессий) — вы не мужик. Ну там фотографировать умеете? Коллажи делать? Полочки вешать, а ля «муж на час»? Витуху прокладывать? Музыку записывать? Статейки писать? Ну наверняка худо-бедно -десяток хобби наберется. А любое хобби может стать источником зарплаты.
Как говорится, наука — это удовлетворение своего любопытства за чужой счет. Для меня программирование — то же самое. То есть немного удивляет, что мне платят, а я не я плачу за доступ к компу и интересным железкам. Мне как-то кажется, что если этого нет, то или профессия выбрана неточно или для вас смысл жизни не в работе, а в семье и детях.
А если хотите остаться в профессии… Подумайте, что вам интересно из прикладной части. Строительство? Изготовление цемента? Транспортировка нефти? Навигация? В любой прикладной части куча интересных задач. Хорошей модели цементной печи до сих пор нету. Люди диссертации пишут о том, как работает цементная печь.
Грубо говоря, если у вас нету десятка профессий (не бумажек, а профессий) — вы не мужик. Ну там фотографировать умеете? Коллажи делать? Полочки вешать, а ля «муж на час»? Витуху прокладывать? Музыку записывать? Статейки писать? Ну наверняка худо-бедно -десяток хобби наберется. А любое хобби может стать источником зарплаты.
Как говорится, наука — это удовлетворение своего любопытства за чужой счет. Для меня программирование — то же самое. То есть немного удивляет, что мне платят, а я не я плачу за доступ к компу и интересным железкам. Мне как-то кажется, что если этого нет, то или профессия выбрана неточно или для вас смысл жизни не в работе, а в семье и детях.
А если хотите остаться в профессии… Подумайте, что вам интересно из прикладной части. Строительство? Изготовление цемента? Транспортировка нефти? Навигация? В любой прикладной части куча интересных задач. Хорошей модели цементной печи до сих пор нету. Люди диссертации пишут о том, как работает цементная печь.
Мне по учебнику — месяц. А сколько вы будете мучаться вашим методом тыка?
Это какая-то ложная дихотомия. Лучше учиться по учебнику, совмещая с методом тыка. Рассмотрел пример, набрал на машине, собрал, запустил. Поменял что-то, посмотрел, что изменилось или сломалось, сделал выводы.
Так обучение проходит сильно глубже, лучше и более надолго.
Ну, можно ещё читать доказательства теорем при изучении какого-нибудь раздела математики, а можно попытаться доказывать их самому и потом, если не получилось, читать авторское доказательство и пытаться понять, где возник затык.
Так что читать учебники и доказательства теорем без всякой практики — это-то как раз и есть каноничное «по верхам».
Поэтому я могу позволить себе изучать технологии под задачу прямо на рабочем месте, а вы ищите себе рабочее место под изученные технологии.
Вопрос приоритетов. Если я очень люблю хаскель, я буду искать места, где пишут на хаскеле. Если я очень люблю деньги, я буду искать места, где платят деньги, а за что — не столь важно, хаскель там, джава или кобол пятидесятилетней давности.
Поменял что-то, посмотрел, что изменилось или сломалось, сделал выводы.
Это и есть метод тыка. Вместо того, чтобы разбираться в коде — тыкает в код палочкой — а вдруг заработает.
В итоге знания примерно на таком уровне:
— а почему ты тут написал именно так?
— куча лапши на уши
— а если честно?
— ну я пробовал, другие варианты не заработали.
То есть решать приведенные в учебнике задачи — надо. А выходить на машину — лишь когда можешь написать код на тысячу строк или более.
Вопрос приоритетов. Если я очень люблю хаскель, я буду искать места, где пишут на хаскеле
Я вот люблю интересную работу, которой можно гордиться. Так что уже 30 лет работаю в очень интересных местах.
Если я очень люблю деньги, я буду искать места, где платят деньги,
Мы себе несколько людей на меньшие зарплаты переманили. Потому что у нас интересно. Работать в стол — многим надоедает.
Вместо того, чтобы разбираться в коде — тыкает в код палочкой — а вдруг заработает.
Наоборот. Потыкать и посмотреть, что сломается, если сделать что-то, для моделирования чего имеющихся знаний ещё недостаточно.
То есть решать приведенные в учебнике задачи — надо.
Надо, конечно. А потом ломать их и курочить.
Я вот люблю интересную работу, которой можно гордиться. Так что уже 30 лет работаю в очень интересных местах.
Что вы называете интересной работой, которой можно гордиться? А то ведь для кого-то это работа, которая максимально улучшает жизнь максимального числа людей, для кого-то — где просто решаются сложные и нерешенные раньше задачи, для кого-то — что-то ещё.
Что вы называете интересной работой, которой можно гордиться?
Есть такая хорошая поговорка: «лучше быть первым деревне, чем вторым в городе»
В идеале — быть единственным в мире, кто нечто может. Это есть в планах, но тут уже начинается NDA и Шахерезада прекращает дозволенные речи.
А реально — ну то, что мы можем — может десяток команд в мире. Причем мы делаем раза в 2 хуже, чем какой-нибудь тримбл и раз в 10 дешевле. Вот только у них — команды по нескольку тысяч работников, а нас — меньше десятка.
Потом может пост напишу про всю эту GPS-кухню.
Вы, к тому же, сами себе противоречите. Выше вы агитируете за «быструю разработку прототипов», а теперь за «написание на бумажке и отладку на компьютере»
У вас очень странная логика. Поясните, плиз, как у вас получается? Вот есть языки, адаптированные к быстрому говорению, например иврит. Есть, наоборот, языки медлительные, вроде финского. Так что, по вашей логике, младенцы сильно быстрее учат иврит, чем финский? :-)))
Интересно, а для изучения английского вам потребовался живой англичанин или хватило его эмулятора? :-)
Интересно, а для изучения английского вам потребовался живой англичанин или хватило его эмулятора? :-)
Для начального уровня хватило эмулятора (собственно, про пользу эмуляторов я выше и писал), начиная с уровня Intermediate понадобился уже живой, т.к. эмуляторов уже не хватало, а что?
Собственно мне очень странно слышать такие рассуждения от АСУТПшника. Вы что, автоматизируете цеха одного типа с одной технологией? Или каждый раз объект автоматизации — разный?
Для меня в АСУТП норма — команда приходит на объект, не зная про технологию почти ничего. А через пару лет, после сдачи системы — обучает тонкостям тех, кто на этом оборудовании 20 лет проработал.
А программные технологии — не сложнее техпроцессов.
Для меня в АСУТП норма — команда приходит на объект, не зная про технологию почти ничего. А через пару лет, после сдачи системы — обучает тонкостям тех, кто на этом оборудовании 20 лет проработал.
А программные технологии — не сложнее техпроцессов.
Мы занимались системами телемеханики для нефтедобывающих объектов, платформа активно развивалась и расширялась с 2007 года и по наши дни — тысячи серийных изделий (замерные установки разных типов, узлы управления задвижками, телеметрия для скважинных насосов, установки подготовки нефти, системы обнаружения утечек, и т.д.) в нескольких странах, и единая система сбора, обработки и визуализации информации со всего этого дела плюс взаимодействие со сторонними системами.
Правда, из сферы АСУТП я в итоге ушел и ни капельки не жалею :)
Сразу юность вспомнилась, 1986ой год, инклинометрия для системы САОБ от СПКБ БА…
Ну бывает и такой АСУТП — тиражный. Просто заказные и полузаказные работы интересней.
Sarcasm on
я правильно понимаю, что уйти с нефти на цемент вы не можете? И даже на газ — очень тяжело? И набирают к вам тех, кто нефтеобработку (ключевую технологию) наизусть знает?
Sarcasm off
Если да, то ваши замечания понятны. Если нет — то выучить новый язык программирования — проще, чем изучить газодобычу или производство цемента.
Ну бывает и такой АСУТП — тиражный. Просто заказные и полузаказные работы интересней.
Sarcasm on
я правильно понимаю, что уйти с нефти на цемент вы не можете? И даже на газ — очень тяжело? И набирают к вам тех, кто нефтеобработку (ключевую технологию) наизусть знает?
Sarcasm off
Если да, то ваши замечания понятны. Если нет — то выучить новый язык программирования — проще, чем изучить газодобычу или производство цемента.
Перейти в другую сферу автоматизации легко ли? Зависит от конкретной ситуации, и от того, насколько адекватно и четко проектный отдел и конструкторское бюро требования и спецификации напишут. И насколько сильно стек технологий различается, опять же. В соседнем отделе, помнится, была как раз соответствующая история — там новенького парня, до этого делавшего интернет-магазины на 1С и PHP, а о Си знавшего только из университета и книг (при том что теоретические знания позволили ему довольно уверенно пройти собеседование с ведущим разработчиком и руководителем отдела), посадили с нуля код довольно серьезной части проекта писать. Матерились потом долго, переписывали еще дольше.
Да и в рамках типовых проектов разные вещи случаются. То на объекте окажется новая ревизия прибора, у которого поменялась карта регистров, а производитель настойчиво присылает старую. Приходится реверсить со сканером, блокнотом и методом дедукции. Или внезапно ставят новый вторичный преобразователь, который обязательно требует при обмене два стоп-бита или вообще бит четности в качестве маркера начала пакета, а USART твоего контроллера такого не умеет и никогда не умел и приходится наводить магию, а по приезду на объект выясняется что магия должна быть чуть-чуть другой, и мучительно переделывается с отладчиком и осциллографом прямо в полевых условиях. Или новый массомер входит в ступор при запросе у него более скольки-то регистров или если попадется неиспользуемый регистр среди используемых в запросе (и ни о чем об этом не упомянуто в документации), в результате чего при отправке четырех запросов вместо одного через медленный радиоканал с большими задержками летят к чертям все рассчитанные тайминги. Всякого разного может быть много.
Далеко не всегда бывает так что «написали и сразу заработало», только в случае заказного проекта стадия «разбираемся на практике» переезжает из теплого офиса на объект во время пусконаладочных работ (и часто занимает в несколько раз больше времени если бы удалось пощупать все заранее), а в случае становления «молодого специалиста» — из этапа «самообучение» на этап «работа», вот только и в первом и втором случае далеко не все заказчики рады за это платить втридорога.
Да и в рамках типовых проектов разные вещи случаются. То на объекте окажется новая ревизия прибора, у которого поменялась карта регистров, а производитель настойчиво присылает старую. Приходится реверсить со сканером, блокнотом и методом дедукции. Или внезапно ставят новый вторичный преобразователь, который обязательно требует при обмене два стоп-бита или вообще бит четности в качестве маркера начала пакета, а USART твоего контроллера такого не умеет и никогда не умел и приходится наводить магию, а по приезду на объект выясняется что магия должна быть чуть-чуть другой, и мучительно переделывается с отладчиком и осциллографом прямо в полевых условиях. Или новый массомер входит в ступор при запросе у него более скольки-то регистров или если попадется неиспользуемый регистр среди используемых в запросе (и ни о чем об этом не упомянуто в документации), в результате чего при отправке четырех запросов вместо одного через медленный радиоканал с большими задержками летят к чертям все рассчитанные тайминги. Всякого разного может быть много.
Далеко не всегда бывает так что «написали и сразу заработало», только в случае заказного проекта стадия «разбираемся на практике» переезжает из теплого офиса на объект во время пусконаладочных работ (и часто занимает в несколько раз больше времени если бы удалось пощупать все заранее), а в случае становления «молодого специалиста» — из этапа «самообучение» на этап «работа», вот только и в первом и втором случае далеко не все заказчики рады за это платить втридорога.
Все, что вы написали — не отличается на нефти, газе, стали или цементе. И даже на Си взамен паскаля — тоже отличий очень мало.
Да, есть специфика у АСУТП. И умение работать с этой спецификой нарабатывается годами. Но эта специфика не зависит ни от языка программирования, ни от объекта автоматизации.
Так что на вопрос вы, увы не ответили. Ну тогда хоть скажите, технологию нефтеобработки вы в институте учили? Или дома самообучением? Или на рабочем месте?
Да, есть специфика у АСУТП. И умение работать с этой спецификой нарабатывается годами. Но эта специфика не зависит ни от языка программирования, ни от объекта автоматизации.
Так что на вопрос вы, увы не ответили. Ну тогда хоть скажите, технологию нефтеобработки вы в институте учили? Или дома самообучением? Или на рабочем месте?
Технологию нефтеобработки я не учил вообще нигде и до сих пор в ней ничего не понимаю. Чтобы преобразовать аналоговый сигнал от уровнемера из емкости, не нужно знать, откуда в эту емкость попала нефть и куда ее будут выкачивать потом. Чтобы дать возможность технологу удаленно просматривать и изменять параметры станции управления скважинным насосом, не нужно знать, что каждый из этих параметров означает. И так далее.
Могу привести другой пример. Моей первой серьезной (как в плане зарплаты, так и в плане интересности и значимости задач) работой было администрирование Linux-серверов в одном большом интернет-провайдере. В первый раз я пришел к ним и сказал «У меня нету почти никакого опыта работы с GNU/Linux, зато у меня отличные навыки использования и настройки Windows от 3.1 до 2000 и я быстро всему обучаюсь» и со мной даже разговаривать не стали. Потом у меня была большая книга по RedHat 6, распечатки man pages с кривыми переводами или вообще без них и интернет на 28800 (по праздникам). И была сначала виртуальная машина, а потом установки на реальное железо, потому что без них это было сродни чтению любовных романов вместо естественных романтических отношений. И через год бессонных ночей и красных глаз, проверок теории на практике, экспериментов, различных конфигураций и применений, все получилось, а я получил возможность заниматься тем, чем хотел, и даже получать за это хорошие деньги.
И это нормально. Тонкости везде познаются в процессе работы, но «база» (в том числе и практическая) нужна всегда независимо от этого. Можно даже сказать, что это закон жизни и рынка труда. Если открыть любую вакансию на hh, indeed или toptal, на позицию не ниже junior'а, то там практически всегда будет что-нибудь вида «Обязателен опыт разработки на C++ с использованием Boost/Qt/MFC/etc. от 6 лет», или «на Java с использованием Spring, Hibernate, JUnit от 3-х лет», и я авторов этих объявлений прекрасно понимаю.
Могу привести другой пример. Моей первой серьезной (как в плане зарплаты, так и в плане интересности и значимости задач) работой было администрирование Linux-серверов в одном большом интернет-провайдере. В первый раз я пришел к ним и сказал «У меня нету почти никакого опыта работы с GNU/Linux, зато у меня отличные навыки использования и настройки Windows от 3.1 до 2000 и я быстро всему обучаюсь» и со мной даже разговаривать не стали. Потом у меня была большая книга по RedHat 6, распечатки man pages с кривыми переводами или вообще без них и интернет на 28800 (по праздникам). И была сначала виртуальная машина, а потом установки на реальное железо, потому что без них это было сродни чтению любовных романов вместо естественных романтических отношений. И через год бессонных ночей и красных глаз, проверок теории на практике, экспериментов, различных конфигураций и применений, все получилось, а я получил возможность заниматься тем, чем хотел, и даже получать за это хорошие деньги.
И это нормально. Тонкости везде познаются в процессе работы, но «база» (в том числе и практическая) нужна всегда независимо от этого. Можно даже сказать, что это закон жизни и рынка труда. Если открыть любую вакансию на hh, indeed или toptal, на позицию не ниже junior'а, то там практически всегда будет что-нибудь вида «Обязателен опыт разработки на C++ с использованием Boost/Qt/MFC/etc. от 6 лет», или «на Java с использованием Spring, Hibernate, JUnit от 3-х лет», и я авторов этих объявлений прекрасно понимаю.
Технологию нефтеобработки я не учил вообще нигде и до сих пор в ней ничего не понимаю.
Мда… Сколько одновременных отказов датчиков сломают вашу систему? Или, как у американцев, после первого отказа летим на 200 км/ч прямо в бетонную стену?
Ну чтобы не быть голословным — задвижка. Два концевика, и датчик тока двигателя. При каком количестве отказов сумеете работать?
Чтобы преобразовать аналоговый сигнал от уровнемера из емкости, не нужно знать, откуда в эту емкость попала нефть и куда ее будут выкачивать потом.
Мда… Печально… Не страшно вам ходить там, где работает ваш код? Вообще-то надо ещё уметь обнаруживать отказы (например — по нулевому шуму), смотреть конфликты показаний разных датчиков, понимать, какое значение стоит показывать при отказе…
Технологию нефтеобработки я не учил вообще нигде и до сих пор в ней ничего не понимаю.
А вот теперь поймите, что возможно и перпендикулярное мнение. То есть специалист в предметной области, который на любом языке пишет как на бэйсике.
А на самом деле нужно что-то среднее — человек, знающий и предметную область и программирование. Причем на новый язык программирования переучить проще, чем объяснить «сферическому программисту в вакууме», почему любые исходные данные могут быть сколь угодно ложными.
там практически всегда будет что-нибудь вида «Обязателен опыт разработки на C++ с использованием Boost/Qt/MFC/etc. от 6 лет»,
Знаете, я тоже напишу в вакансии «нужен программист RTK со стажем от 5 лет.» Только таких в России — не больше 50, скорее 15-20. И если кто захочет к нам перейти -это и так будет известно. поэтому реальные требования:
- Высокая самообучаемость по книгам
- Умение доводить задачу до конца
- Опыт работы с кодом не менее 30 тысяч строк (для умного студента — 10 тысяч строк)
- Умение работать на износ в командировках
- Понедельник начинается в субботу
Мда… Сколько одновременных отказов датчиков сломают вашу систему?
Два концевика, и датчик тока двигателя. При каком количестве отказов сумеете работать?
В большинстве случаев диагностикой сигналов вообще занимаются вторичные преобразователи, а нам достаточно только с них биты состояния взять. В иных случаях диагностики были вообще школьного уровня, честно говоря, и объяснялись они "на пальцах" за полчаса (типа если у аналогово датчика на 4-20 мА ток выходной сигнал выходит за эти пределы, значит с ним что-то не так, пусть киповцы дальне разбираются). А других и не надо, это телеметрия и телемеханика. По сути дела — обычный щит управления, только виртуальный и на расстоянии. И отказ какого-то блока или даже целой установки не остановит процесс фатально — просто у операторов, диспетчеров или технологов временно станет чуть больше работы.
То есть специалист в предметной области, который на любом языке пишет как на бэйсике.
Так это и страшно. Обычно "специалисты", кричащие, что "пишут на любом языке как на бэйсике", как раз пишут на любом языке как на бэйсике. С понятными последствиями.
Знаете, я тоже напишу в вакансии «нужен программист RTK со стажем от 5 лет.» Только таких в России — не больше 50, скорее 15-20.
И к чему это сказано-то? Вы если напишите, то не будете рассматривать это требование как обязательное (типа, чему надо — научим)? А вот те, кто пишут
«Обязателен опыт разработки на C++ с использованием Boost/Qt/MFC/etc. от 6 лет»чаще рассматривают эти требования как обязательные, и очень серьезно и тщательно спрашивают об этом на собеседованиях. В том то и дело, что при нормально поставленном процессе разработки не нужно быть экспертом во всем. Техзадание и детальные требования формулируют аналитики, спорные вопросы у закачика проясняют менеджеры, интерфейсы рисуют дизайнеры, а программисты превращают все это в код. Как вы сами говорили, лучше не "знать все по-маленьку", а делать что-то одно, но делать это очень хорошо.
Опыт работы с кодом не менее 30 тысяч строк (для умного студента — 10 тысяч строк)
В целом, я начинаю понимать причину вашей категоричности. Вы, видимо, большую часть своей жизни работали в "наукоемких" проектах, где, как вы выше упоминали, основную сложность предоставляет не сама предметная область, а не ее реализация в программе (и кода "от 30 тысяч строк").
У меня же встречались проекты, где "предметная область" довольно широка, но каждую ее составную часть можно объяснить за полчаса "на пальцах" независимо от другой, и при этом во всем проекте более ста миллионов строк кода на двух языках (это без учета полусотни сторонних библиотек), несколько десятков тысяч юнит-тестов, периодически нужно лазить по всему этому сразу, главными требованиями являются производительность и стабильность, а новый функционал нужно встраивать нежно, но быстро (плюс постоянный рефакторинг). В одном случае с программированием разберется даже студент, а вот с предметной областью — нет, а в другом же случае все в точности наоборот.
Умение работать на износ в командировках
такие вещи надо в самом начале вакансии писать, чтобы люди не тратили время на дальнейшее чтение :)
Прошу прощения за опечатку (edit уже не работает), в предпоследнем блоке «основную сложность предоставляет не сама предметная область»
И отказ какого-то блока или даже целой установки не остановит процесс фатально
Мда, теперь все понятно. При таком уровне понимания сути работы — действительно, только вызубривание десятка тысяч вызовов API может вам помочь.
На досуге почитайте, к чему приводит такой подход в АСУТП.
Обычно «специалисты», кричащие, что «пишут на любом языке как на бэйсике», как раз пишут на любом языке как на бэйсике. С понятными последствиями.
Известные мне последствия — сотня институтов СССР считала по этой программе прочность зданий. Тысячи построенных цехов. Ни один по вине программы не упал. Один из разработчиков — стал академиком архитектуры. Несколько написанных учебников по сопромату в качестве утилизации отходов от придумывания алгоритмов. Но код… это был фортран. даже не так — ФОРТРАН, точнее ФОРТРАНИЩЕ. Система ввода данных была запутана так, что без высшего образования — данные не введешь. Зато глупостей с подсчетом рядов не в ту сторону (надо от меньших к большим) — не было. А вы какие последствия имели ввиду?
В том то и дело, что при нормально поставленном процессе разработки не нужно быть экспертом во всем.
Экспертом и не нужно, но бела в том, что вы-то азы не понимаете. Аналитик многие вещи считает само собой разумеющимися, менеджеры и тестеры вообще про секреты полишинеля не знают. А в итогу — конец света. Лучше уж «как на бейсике», но писать с пониманием предметной области.
Вы, видимо, большую часть своей жизни работали в «наукоемких» проектах
А любой АСУТП — наукоемок. Вы все-таки подумайте над задачкой про концевик. Интересно, сумеете её решить или нет?
Собственно дело не в наукоемкости, а в инженерии, в know-how. Как писал Фейнман «это уже не наука. То, что какая-то штука не является наукой, не делает её плозой. Любовь — хорошая штука, но не наука она и все тут». Но быть инженером и уметь решать инженерные задачи — нужно обязательно. А без этого — только зубрить тысячи вызовов API.
Помните байку про то, как Эйнштейн нанимался помощником к Эдисону? Что-то вот сильно на неё похоже.
и кода «от 30 тысяч строк»
От 30 тысяч строк можно легко прыгнуть на 200 тысяч. А вот от тысячи строк — прыжок не выйдет. Что и показала ваша история про javascriptшика, начавшего писать на Си.
такие вещи надо в самом начале вакансии писать, чтобы люди не тратили время на дальнейшее чтение :)
Для умеющих читать — это плюс к вакансии. Работа на износ в командировках означает, что вне аврала можно просто позвонить и не пойти на работу. Аврал и отгул — это две стороны одной медали. А не умеющие читать нам не нужны.
чаще рассматривают эти требования как обязательные, и очень серьезно и тщательно спрашивают об этом на собеседованиях.
Угу. эйчары на собеседованиях спрашивают. Нужно же как-то полных идиотов отбраковать! :-) А реально из десятка таких пунктов ни один не является критичным. Ну как минимум для сеньора.
при этом во всем проекте более ста миллионов строк кода
Остапа понесло…
Для умеющих читать — это плюс к вакансии. Работа на износ в командировках означает, что вне аврала можно просто позвонить и не пойти на работу. Аврал и отгул — это две стороны одной медали. А не умеющие читать нам не нужны.
Это скорее не для «умеющих читать», а для «обладающих богатой фантазией». Обычно это означает «работа в офисе с 9 до 18, а в командировках длительностью по несколько недель — с 7 до 23, и не факт что вам сильно за это доплатят». Такое повсеместно встречается, кстати.
А вы какие последствия имели ввиду?
На «до костей» ООП-языке типа можно нарушить все принципы SOLID, а можно умудриться написать код в процедурном стиле с тонной глобальных переменных и goto. На языке для асинхронной однопоточной среды выполнения можно упороться и написать блокирующий код или наоборот устроить callback hell. Даже на современном C++ можно писать код с голыми указателями вместо shared_ptr и unique_ptr и Си-строками вместо std::string. Можно написать сложную систему с кучей связей и не написать ни одного юнит-теста.
И в итоге все это выливается в то, что код будет работать и программа даже будет выполнять поставленную задачу. Но она будет написано неэффективно, немасштабируемо, и нетестируемо. Что в итоге выльется в убытки в будущем.
Угу. эйчары на собеседованиях спрашивают.
В приличных компаниях эйчары технические вещи вообще не спрашивают. Спрашивают технические специалисты — непосредственные будущие коллеги (или приглашенные программисты из соседних команд) и руководители.
Остапа понесло…
Что вас смущает? Я, по факту, даже преуменьшил объем кодовой базы, но самом деле все еще сложнее. Или вы не верите, что такие проекты существуют и над ними реально работают люди?
Перепроверил насчет строк — поправлюсь, сто миллионов это с внешними библиотеками, зависимостями, старыми ревизиями и подобным (хотя во все это тоже периодически лазить приходится).
«Чисто» кода же в проекте 16 миллионов строк без комментариев (21 миллион с считая комментарии), и более 50 тысяч юнит- и интеграционных тестов.
«Чисто» кода же в проекте 16 миллионов строк без комментариев (21 миллион с считая комментарии), и более 50 тысяч юнит- и интеграционных тестов.
Такое впечатление, что у вас и зарплата черная. Или серая. При белой — есть КЗоТ, и все переработки должны оплачиваться.
В итоге выливается в прибыли в настоящем и в возможные убытки в будущем. Это называется технический долг. Как и финансовым долгом — им нужно уметь управлять. Вспоминаем про как Вася и Петя одновременно начали писать один и тот же продукт
Вполне разумная стратегия. Выпустить продукт, собрать сливки с рынка, а потом нанятьдешевых кодеров для переписывания по феншую.
Это такая деформация сознания у кодеров — «эффективность, масштабируемость, тестируемость» — и ни слова о том, за что продукт покупают. А покупают не за тестируемость, и даже не за эффективность в смысле использования ЦПУ, а за удовлетворение потребностей пользователя.
Какая разница покупателю, масштабируется ли схема телевизора на другой размер экрана? Какая разница, как насколько эффективно используется ЦПУ в видеопроцессоре того же телевизора? Качество картинки и внешний вид — намного важнее.
Вы судите с позиции производителя, а не покупателя.
Да и с позиций производителя — не все так просто. Можно сделать схему того же телевизора под все размеры экрана, 20 лет выпускать её с мелкими модернизациями и отстать от прогресса. А можно — раз в год делать совсем новую схему, на современных компонентах.
В больших компаниях заказ на специалистов идет к эйчарам. И они проверяют технические скилы ещё до всяких интервью. На этом этапе иногда и название работодателя не говорят. Меня на такие собеседования звали, пару раз сходил. Возможно, это относится лишь к переманиванию, ибо обычно такие данные есть в резюме, а я никаких резюме не писал.
Сложно придумать задачу, для которой 50 тысяч человеко-лет является разумным объемом. Нагородить-то кода можно сколько угодно, вот только несоразмерный задаче объем кода — означает, что проект плох. Точнее — очень плох.
Да и ситуация, когда мы имеем монолит такого объема — или очень особая или следствие плохого дизайна. То есть лучше бы разбить намикросервисы нормального размера.
Что за задача такая, неназываемая? Вызов черного властелина?
Но она будет написано неэффективно, немасштабируемо, и нетестируемо. Что в итоге выльется в убытки в будущем.
В итоге выливается в прибыли в настоящем и в возможные убытки в будущем. Это называется технический долг. Как и финансовым долгом — им нужно уметь управлять. Вспоминаем про как Вася и Петя одновременно начали писать один и тот же продукт
Вполне разумная стратегия. Выпустить продукт, собрать сливки с рынка, а потом нанять
Это такая деформация сознания у кодеров — «эффективность, масштабируемость, тестируемость» — и ни слова о том, за что продукт покупают. А покупают не за тестируемость, и даже не за эффективность в смысле использования ЦПУ, а за удовлетворение потребностей пользователя.
Какая разница покупателю, масштабируется ли схема телевизора на другой размер экрана? Какая разница, как насколько эффективно используется ЦПУ в видеопроцессоре того же телевизора? Качество картинки и внешний вид — намного важнее.
Вы судите с позиции производителя, а не покупателя.
Да и с позиций производителя — не все так просто. Можно сделать схему того же телевизора под все размеры экрана, 20 лет выпускать её с мелкими модернизациями и отстать от прогресса. А можно — раз в год делать совсем новую схему, на современных компонентах.
В приличных компаниях эйчары технические вещи вообще не спрашивают.
В больших компаниях заказ на специалистов идет к эйчарам. И они проверяют технические скилы ещё до всяких интервью. На этом этапе иногда и название работодателя не говорят. Меня на такие собеседования звали, пару раз сходил. Возможно, это относится лишь к переманиванию, ибо обычно такие данные есть в резюме, а я никаких резюме не писал.
Что вас смущает?
Сложно придумать задачу, для которой 50 тысяч человеко-лет является разумным объемом. Нагородить-то кода можно сколько угодно, вот только несоразмерный задаче объем кода — означает, что проект плох. Точнее — очень плох.
Да и ситуация, когда мы имеем монолит такого объема — или очень особая или следствие плохого дизайна. То есть лучше бы разбить на
Что за задача такая, неназываемая? Вызов черного властелина?
При белой — есть КЗоТ, и все переработки должны оплачиваться.
Я слышал, при белой зарплате есть такой финт, как формально ненормированный рабочий день.
Такое впечатление, что у вас и зарплата черная. Или серая. При белой — есть КЗоТ, и все переработки должны оплачиваться.
О нет, все легально и полностью по ТК.
Просто современный трудовой кодекс не регламентирует длительность и частоту командировок. Вообще никак.
Фронт работ обозначен и должен быть выполнен, и в итоге у работника есть выбор: работать размеренно по 9 часов в день и увидеть свою семью только через месяц, или по собственному желанию и за свой счет впахивать сверхурочно, чтобы вернуться к жене и детям на две недели раньше.
А еще есть третий вариант, после полугода издевательств послать всех в литую кружку, уволиться, и в следущий раз хорошо подумать, прежде чем подписываться на работу с командировками.
В больших компаниях заказ на специалистов идет к эйчарам. И они проверяют технические скилы ещё до всяких интервью
Эйчары не могут проверять технические скилы, потому что сами ими не обладают :) Полистайте хабр, тут было много статей, где люди делились опытом прохождения собеседований. Задача HR'а — отфильтровать явных неадекватов и совсем нерелеватных личностей из стопки резюме на почте или линкедине, а потом назначить встречу и передать кандидата в руки технарям.
Что за задача такая, неназываемая? Вызов черного властелина?
Всё просто: www.chromium.org/Home
Точнее не сам chromium, а его адаптация и существенная доработка для узкоспециализированных задач и интероперабильности с другими компонентами одной платформы (со своей операционной системой).
Хотя в апстрим доработки и исправления тоже отправляем.
в следущий раз хорошо подумать, прежде чем подписываться на работу с командировками.
Не знаю, я командировку воспринимаю как поощрение. Типичная командировка это в 5-30 утра из Питера, в 9 утра в Москве, к обеду все показали, к 7 вечера в Питере. Или, как вариант — встретиться с Московскими друзьями и быть в Питере к 23 часам. Бывает и на несколько дней, но все равно, как правило — командировки это интересно.
Полистайте хабр, тут было много статей, где люди делились опытом прохождения собеседований.Угу, вот вам пример с хабра, как эйчары технические скилы проверяют:
— Ну ладно. Вот вам простой вопросик. Что означает буква L в аббревиатуре SOLID?
— Liskov Substitution Principle.
— Нет. У меня написано, что это Liskov Substitutability Principle.
не могут проверять технические скилы, потому что сами ими не обладают :)
Вы серьезно думаете, что музыковеды дают концерты, а кинокритики снимают кино? Да и в программировании — не надо знать язык, чтобы исправлять ошибки в коде.
30 лет назад
Точнее не сам chromium, а его адаптация и существенная доработка для узкоспециализированных задач и интероперабильности с другими компонентами одной платформы
Ну то есть правильно не верил. Кодовая база велика, но написана на 99.9% не вами.
Типичная командировка это в 5-30 утра из Питера, в 9 утра в Москве, к обеду все показали, к 7 вечера в Питере.
В таком режиме — да. Но жизнь, к сожалению, состоит не только из идеальных случаев.
Угу, вот вам пример с хабра, как эйчары технические скилы проверяют:
— Ну ладно. Вот вам простой вопросик. Что означает буква L в аббревиатуре SOLID?
— Liskov Substitution Principle.
— Нет. У меня написано, что это Liskov Substitutability Principle.
Это уж совсем какие-то упоротые. Не имел опыта сталкиваться с такими, к счастью. В некоторых случаях рекрутеры высылали пробное задание или просили пройти тест, и результаты всего этого всё равно потом передавались специалистам, и дальшнейшее взаимодействие было уже с ними.
Дураки и дилетанты везде есть, но в хороших компаниях они обычно надолго не задерживаются.
Ну и, пожалуй, приложу картинку в тему.
Не говоря уж о том, что пример с Liskov Substitution Principle приведен из вообще по большей части выдуманного сатирическо-гиперболизированного диалога :)
Это уж совсем какие-то упоротые. Не имел опыта сталкиваться с такими, к счастью.
Это обычная вещь при переманивании. У рекрутингового агентства — портфель заказов на разные профили. И они шерстят соцсети и все остальное и смотрят, а кто куда годится. Если человек и не думает о смене работы — его сложно уговорить написать резюме. А вот заманить на такое собеседование — чуть проще. Любопытно же, кто это и куда тебя хочет на работу позвать. :-) А что это рекрутеры просто собирают базу — выясняется уже когда пришел.
Типичная командировка это в 5-30 утра из Питера, в 9 утра в Москве, к обеду все показали, к 7 вечера в Питере.
Встать в 5:30 для меня само по себе уже наказание.
А если я приду на работу в 5:30 утра, то дома я буду часа в три дня максимум уже, не в 7.
встал часов в 15 часов, в 22 часа на работе, к 4 утра все проверил, упаковал и на такси.
Хиппи встали рано, солнце только что закатилось
Служил Гаврила программистом,
Гаврила толку в программах знал.
На перфокарты поле чистом
Гаврила дырки протыкал.
Не знал Гаврила расписанья,
Он не любил себя стеснять,
Он приходил в ВЦ к обеду
И утром уходил поспать.
Гаврила толку в программах знал.
На перфокарты поле чистом
Гаврила дырки протыкал.
Не знал Гаврила расписанья,
Он не любил себя стеснять,
Он приходил в ВЦ к обеду
И утром уходил поспать.
Какая разница покупателю, масштабируется ли схема телевизора на другой размер экрана?
Ну речь-то не про схемотехнику, а про софт. С ним очень просто. Когда завод-производитель матриц наконец-то выпускает новую сколько-то-там-K панель, фирма A просто меняет пару констант в прошивке, ставит процессор по-мощнее из той же линейки, и выкатывает новый телевизор на рынок на 3 месяца раньше своих конкурентов B, пока те переписывают прибитые гвоздями куски кода и в панике борятся с непонятно откуда возникшими багами в процессе адаптации ПО.
Какая разница, как насколько эффективно используется ЦПУ в видеопроцессоре того же телевизора?
Повысив эффективность использования ЦП можно при удовлетворении тем же требованиям к конечному продукту поставить младший (более дешевый) чип на плату, который будет стоить на 10$ дешевле — покупателю бонус небольшой (в масштабах стоимости всего продукта), а производитель при производстве 10 тысяч телевизоров экономит 100 тысяч долларов, которые может вложить в R&D, например.
Можно сделать схему того же телевизора под все размеры экрана, 20 лет выпускать её с мелкими модернизациями и отстать от прогресса. А можно — раз в год делать совсем новую схему, на современных компонентах.
Звучит как «Можно написать программный продукт, и в каждом релизе вносить в него изменения для добавления функционала, исправления ошибок и удовлетворения пожеланий заказчиков, а можно каждый год выкидывать все и писать с нуля».
Когда завод-производитель матриц наконец-то выпускает новую сколько-то-там-K панель, фирма A просто меняет пару констант в прошивке
Увы, технологии меняются. А новая технология — новый код.
Повысив эффективность использования ЦП можно при удовлетворении тем же требованиям к конечному продукту поставить младший (более дешевый) чип на плату
Увы, не выйдет. Чип определяется пиковым потреблением CPU. А пиковый процесс (0.001% кода) и так вылизан.
Звучит как «Можно написать программный продукт, и в каждом релизе вносить в него изменения для добавления функционала, исправления ошибок и удовлетворения пожеланий заказчиков, а можно каждый год выкидывать все и писать с нуля».
Именно так. И это правильно. Ну как пример. Когда вышел STM32F7 и на горизонте замаячил STM32H7 — мы выкинули все железо и сделали заново. Без внешних микросхем памяти и flash, без linux, на голом Soc и FreeRTOS. И получили удешевление В РАЗЫ. И новый рынок — беспилотники, там очень важен вес и размер платы.
Шли бы эволюционным путем — до сих пор бы сидели даже не на linux, а на x86 и MS-DOS.
А выигрывает именно тот, кто готов переписать сове решение под новые технологии.
Увы, технологии меняются. А новая технология — новый код.
Код графической подсистемы, отвечающий за масштабирование виджетов, конфигурацию декодеров видеопотоков, выбор дефолтного разрешения при стриминге и т.д. вообще никак не зависит от самой технологии изготовления матрицы :)
Увы, не выйдет. Чип определяется пиковым потреблением CPU. А пиковый процесс (0.001% кода) и так вылизан.
Заменяем формулировку на «повысив эффективность использования ЦПв пиковых процессах», и вот оно.
А выигрывает именно тот, кто готов переписать сове решение под новые технологии.
Если у вас был такой опыт, то это вообще не значит, что везде и всегда так. Меня недавно знакомые звали в одну компанию, у них основной продукт — сложная система хранения огромных массивов данных для разных энтерпрайзных целей. Так вот, система ведет свою историю с начала 90-х годов (начиная свой путь еще с древних SCO UNIX и Solaris), и до сих пор в системе есть модули с кодом из тех времен. И грамотно спроектированная архитектура всего этого дела позволяет развивать продукт и удеживать лидирующие позиции на рынке, до сих пор все отлично работает, развивается, если разработчики вынуждены затронуть легаси-код, то он рефакторится, затронутые части переписываются под современные стандарты и документируются, в итоге клиенты получают требуемый функционал и полную обратную совместимость, и т.д. Архитектура и части ядра в процессе эволюции у них тоже менялись, и это не требовало выбрасывать всю «обвязку». Если бы разработчики бросали все каждые N лет при выходе новой ОС или платформы и начинали писать все заново, они бы никогда вообще не смогли выпустить ни одной новой версии своего продукта — с учетом его сложности, он бы устаревал быстрее, чем выходила бы новая ОС или аппаратная платформа.
Код графической подсистемы, отвечающий за масштабирование виджетов, конфигурацию декодеров видеопотоков, выбор дефолтного разрешения при стриминге и т.д. вообще никак не зависит от самой технологии изготовления матрицы :)
Сказочки. Много ли программ, сделанных во времена 640 на 480 способны красиво масштабировать на экранах в 10-20 мегапикселей? Ну там шрифт нормально отрисовать, например? Знаете такие программы? я вот не — знаю.
Заменяем формулировку на «повысив эффективность использования ЦПв пиковых процессах», и вот оно.
Это не отрицает наличие технического долга во всех остальных вещах. Согласен, есть вещи, где технический долг неуместен, и это одна из них.
система ведет свою историю с начала 90-х годов (начиная свой путь еще с древних SCO UNIX и Solaris), и до сих пор в системе есть модули с кодом из тех времен.
Повезло, что это не система 50ых годов и написана она не COBOL. Такие мастодонты тоже есть, особенно в правительственных структурах США.
Вот только скоро их обойдет какой-нибудь выскочка. Примерно как гугл обошел старичков с их вылизанной архитектурой.
Много ли программ, сделанных во времена 640 на 480 способны красиво масштабировать на экранах в 10-20 мегапикселей?
Так я о том и говорю, разработчики этих программ не ставили себе такую цель (или вообще не задумывались, что может возникнуть такая проблема), что потом обернулось проблемами.
Современные Qt-based приложения, например, отлично ресайзятся от крохотных экранчиков до HiDPI (Retina) дисплеев.
Вот только скоро их обойдет какой-нибудь выскочка.
Сильно сомневаюсь. Они идут в ногу со временем и не брезгуют новыми технологиями (и даже сами их создают), и имеющийся у них базис позволяет использовать новые технологии и подходы не выкидывая все что было нажито тяжким трудом и кучей ресурсов и приносящее хорошие деньги.
Так-то если посмотреть по сторонам, то такие примеры на каждом шагу. Ядра двух самых распространенных в мире операционных систем ведут историю разработки тоже из начала 90-х годов, и при этом активно развиваются, не устаревая ни морально, ни технически, отлично масштабируются для работы в любых условиях, то наручных часов до научных суперкомпьютерных кластеров, о количестве поддерживаемых архитектур и говорить нечего. А уж среди прикладного ПО подобных примеров еще больше.
Да, бывает когда продукт закапывают и заменяют на новый — но такое обычно бывает или при каких-то совсем революционных изменениях, или когда становится ясна тупиковость ветви развития (как, например, Adobe недавно закопала Flash), что все-таки случается не каждый год, а во много раз реже.
Так я о том и говорю, разработчики этих программ не ставили себе такую цель
А этим и отличается использование новой технологии вместо масштабирования старой. Грубо говоря, автомобиль — это не лошадь, лошадиная инфраструктура ему не очень подходит.
Ядра двух самых распространенных в мире операционных систем ведут историю разработки тоже из начала 90-х годов, и при этом активно развиваются, не устаревая ни морально, ни технически,
Зато ещё две — сдохли. Я про Windows (не NT) и UNIX (не linux).
Да, бывает когда продукт закапывают и заменяют на новый — но такое обычно бывает или при каких-то совсем революционных изменениях, или когда становится ясна тупиковость ветви развития
Да ну? Linux почему закопал UNIX? Что-то революционное? Тупиковая ветка? Просто UNIX перестал развиваться из-за своей древности.
UNIX даже в 1990 году был безнадежно стар. Например, в нем не было нативной поддержки русского языка — символы ASCII были 7битные. Для года его создания — нормально. Для 1990ого года — ужас. Две русские локализации (ИНМОС и ДЕМОС) независимо друг от друга перерабатывали ядро на 8битный ASCII. Это ещё один пример «Новой технологии», которую создатели не предусмотрели.
все-таки случается не каждый год, а во много раз реже.
От размера программ зависит. Чем программа больше — тем реже меняется лидер. Чем меньше — тем быстрее.
Грубо говоря, автомобиль — это не лошадь, лошадиная инфраструктура ему не очень подходит.
Разумно. Но это не значит, что с выходом каждой новой модели автомобиля мы должны строить по всей стране новые дороги.
С автомобилями, кстати, пример показательный. Если сравнивать конструкции моторов разных лет от тех же Renault, то можно проследить инженерную родословную аж до 30-х годов прошлого века — как перенесли распредвал с низа в верх, как убрали коромысла, как добавили электронный впрыск, и т.д. И даже при переходе на производство гибридов и электромобилей автопроизводителям не пришлось как-то особенно модифицировать подвеску, придумывать принципиально новую конструкцию фар ближнего света, переизобретать ремни безопасности, делать восемь дверей вместо четырех и добавлять машине дополнительные два колеса — новая силовая установка и накопители энергии отлично вписались в существующую архитектуру (и даже Tesla, выдвигая на рынок свой «революционный» электромобиль, сконструировала его на уже существовавшем шасси Lotus).
Linux почему закопал UNIX? Что-то революционное? Тупиковая ветка?
Если не считать HP UX, AIX, Solaris, то корни «того самого» UNIX (пусть и переписанные по-частям из-за лицензионных и юридических проблем) до сих пор живут в современных FreeBSD и Darwin (macOS/iOS).
И даже если это считать смертью системы, то она уверено держала позиции на рынке несколько десятков лет (в том числе за счет удачной архитектуры), да и компании, которые ее разрабатывали и продавали, сейчас не бедствуют. Если бы они бросались писать с нуля новую операционную систему каждые несколько лет по веянию моды — было бы всем лучше? Сомнительно.
Как обратный пример можно посмотреть на современный мир фронтенд-разработки — там «принципиально новый» фреймворк выходит каждые полгода, и «лидер» меняется каждые пару лет, но в среде корпоративной разработки обычно никто не бегает кругами с криками «обожемой, срочно бросаем все и переписываем весь проект с кнокаута на реакт!!!!1».
Но это не значит, что с выходом каждой новой модели автомобиля мы должны строить по всей стране новые дороги.
У нас в Питере — пришлось. Торцовая мостовая отлично поглощала звук копыт, но была очень неудобна для шин. Сено, бензин, газ, электричество — настолько разные, что для них пришлось строить разные сети заправок. Даже бензин с газом на одной заправке не живут.
А то, что вы описываете — это не новые технологии, это модернизации старых. А вот распредвал — пришлось убрать, электромобили живут без него.
Если бы они бросались писать с нуля новую операционную систему каждые несколько лет по веянию моды — было бы всем лучше?
Так по факту они и бросились. Linux, FreeBSD, QNX написаны с нуля. По старым чертежам — но с нуля.
И дело не только в патентных ограничения.
в среде корпоративной разработки обычно никто не бегает кругами с криками «обожемой, срочно бросаем все и переписываем весь проект с кнокаута на реакт!!!!1».
А в мобильном мире — переписали всё. У меня андроид 1.5 — на нем не работает практически ничего, включая большинство сайтов. Обновления на мобильник выходят максимум год-два. Потом — новая платформа, а старая модель забрасывается.
Аналогично — с чипсетами на десктопах. Давно прошли те времена, когда можно было сменить процессор компу пятилетней давности. Сейчас раз 2-3 года — меняется даже сокет, не говоря уж о чипсете.
В целом — бывает очень по-разному. То, что я описываю — ярче всего видно именно в мобильниках и чипсетах для них. Выпустили мобильник с багами, с техническим долгом — и все, переключились на новую модель и новый чипсет.
Аналогично — с процессорами. Там огромные errata, которые никто не собирается исправлять.
И все равно не убедили.
Пример из жизни: у меня жена работает в команде, пишущей софт под заказ для одного большого европейского банка. Скажем так, связанный с определенным видом торгов на бирже. Развитие идет активно, новые пожелания и требования выдвигаются каждые пару месяцев,
Так вот, у них все спроектировано удачно, так, что когда банк начинает свою деятельность в какой-то новой для себя стране, где свои законы и особенности, им нет необходимости вносить изменения в полсотню захардкоденных мест, а достаточно описать все условия в централизованном репозитарии. Когда заказчики захотели в дополнение к веб-версии еще приложения для iPad, разработчикам не пришлось перепахивать половину серверной части, а достаточно было просто добавить пару rest endpoints на бэкенде. В преддверии политических или экономических потрясений (типа Brexit'а), когда объем торгов может возрасти в десяток, а то и в сотню раз, а любые тормоза или даунтайм — потеря огромных денег и репутации, достаточно только арендовать еще десяток серверов у хостера и буквально одним движением развернуть на них дополнительные инстансы, которые сразу войдут в существующую систему и затащат взлетевшую нагрузку.
В каком случае заказчику нужно будет бросить все, и начать делать с нуля полностью новое ПО? Либо при серьезных переменах в самой отрасли (например, повсеместный переход для блокчейн со смарт-контрактами для оборота ценных бумаг), либо при технической невозможности продолжать разработку старого продукта (JVM и Linux стали дремучим legacy и все перешли на что-то иное — хотя пример с COBOL в виртуалках какбэ намекает).
Если бы на каждое из требуемых нововведений заказчику нужно было бы каждый раз заказывать новый продукт и ждать его разработки (и платить за выкидывание всего и полное переписывание из своего кармана), то наврядли бы сотрудничество этих заказчиков и разработчиков было бы долгосрочным и успешным.
Пример из жизни: у меня жена работает в команде, пишущей софт под заказ для одного большого европейского банка. Скажем так, связанный с определенным видом торгов на бирже. Развитие идет активно, новые пожелания и требования выдвигаются каждые пару месяцев,
Так вот, у них все спроектировано удачно, так, что когда банк начинает свою деятельность в какой-то новой для себя стране, где свои законы и особенности, им нет необходимости вносить изменения в полсотню захардкоденных мест, а достаточно описать все условия в централизованном репозитарии. Когда заказчики захотели в дополнение к веб-версии еще приложения для iPad, разработчикам не пришлось перепахивать половину серверной части, а достаточно было просто добавить пару rest endpoints на бэкенде. В преддверии политических или экономических потрясений (типа Brexit'а), когда объем торгов может возрасти в десяток, а то и в сотню раз, а любые тормоза или даунтайм — потеря огромных денег и репутации, достаточно только арендовать еще десяток серверов у хостера и буквально одним движением развернуть на них дополнительные инстансы, которые сразу войдут в существующую систему и затащат взлетевшую нагрузку.
В каком случае заказчику нужно будет бросить все, и начать делать с нуля полностью новое ПО? Либо при серьезных переменах в самой отрасли (например, повсеместный переход для блокчейн со смарт-контрактами для оборота ценных бумаг), либо при технической невозможности продолжать разработку старого продукта (JVM и Linux стали дремучим legacy и все перешли на что-то иное — хотя пример с COBOL в виртуалках какбэ намекает).
Если бы на каждое из требуемых нововведений заказчику нужно было бы каждый раз заказывать новый продукт и ждать его разработки (и платить за выкидывание всего и полное переписывание из своего кармана), то наврядли бы сотрудничество этих заказчиков и разработчиков было бы долгосрочным и успешным.
В каком случае заказчику нужно будет бросить все, и начать делать с нуля полностью новое ПО?
Не тот вопрос! Правильный вопрос: когда стартап, пишущий с нуля, получает техническое преимущество над монстром с долголетней архитектурой? Частеньно.
При этом у монстра — стократное преимущество в программистах, но оно не помогает. На каждого монстра — тысячи стартапов и рано или поздно его одолеют.
Что может сделать монстр для защиты? Идти по пути стартапа, то есть переписывать свой к нуля.
Когда заказчики захотели в дополнение к веб-версии еще приложения для iPad, разработчикам не пришлось перепахивать половину серверной части,
Телевизор — это клиентская часть, серверная — телестудия. Что с клиентской частью для IPAD? JS образца 1997 года? JAVA? Что-то новое и нативное, написанное с нуля?
Думаю, что плюнули они на свою наработанную архитектуру и написали нативного клиента с нуля. И это правильно.
А замена стандартов в серверной части действительно происходит очень медленно. Цветное телевидение вводилось 30 лет. Так что не спорю, что в серверной части эволюционный путь лучше. А в клиентской с её быстрой сменой стандартов?
Телевизор — это клиентская часть, серверная — телестудия.
Хорошая аналогия, только, скорее, не телестудия, а телевышка. В плохо спроектированном ПО как раз-таки можно встретить случаи, когда невозможно запустить вещание еще одного телеканала, потому что места под еще одну антенну вроде есть, но вот еще один фидер в кабельную шахту не влезает, а вещание на новостройки на юге города организовать без глобальной пере-стройки в принципе невозможно, потому что с той стороны гора, а о том что город может начать расти на юг при строительстве телевышки пять лет назад никто вообще и не подумал.
И переход на кабель и IPTV не панацея — при плохом подходе к делу там рано или поздно возникнут аналогичные проблемы.
А в клиентской с её быстрой сменой стандартов?
Так во-первых и нужно обеспечить быструю смену клиентов без неоьходимости переписывания каждый раз ядра системы, а во вторых, со стороны клиентов развитие тоже не всегда молниеносно,
буквально вчера на HighLoad++ об этом говорили, вот тут www.youtube.com/watch?v=Ygfwwd490mk с 3:03:00 рассказывают, как внося новый функционал, разработчики сохраняют совместимость с почти сотней (!) разных версий клиентов на разных платформах.
Опечатался, с 6:03:00, а не 3:03:00
Повторю вопрос. Что с клиентской частью для IPad? JS образца 1997 года? JAVA? Что-то новое и нативное, написанное с нуля?
Именно телестудия. Телевышка — это транспорт, аналог сети. Ваш пример про то, что иногда жирные приложения не влезают в пропускную способность сети. А мой — про то, что на телестудия до сих пор используется аналоговое оборудование чуть ли 1955ого года выпуска.
Это как в фотографии — в массовом сегменте цифра, а как нужны сотни мегапикселей для рекламных плакатов — так фотопластинки и довоенная камера с мехами.
Хорошая аналогия, только, скорее, не телестудия, а телевышка.
Именно телестудия. Телевышка — это транспорт, аналог сети. Ваш пример про то, что иногда жирные приложения не влезают в пропускную способность сети. А мой — про то, что на телестудия до сих пор используется аналоговое оборудование чуть ли 1955ого года выпуска.
Это как в фотографии — в массовом сегменте цифра, а как нужны сотни мегапикселей для рекламных плакатов — так фотопластинки и довоенная камера с мехами.
А мой — про то, что на телестудия до сих пор используется аналоговое оборудование чуть ли 1955ого года выпуска.
А вот это плохой пример. Как человек, ранее имевший некое отношение к телевидению, могу сказать, что снимают, монтируют и вещают давно уже в цифре (ну за исключением разве что провинциальных студий). Как уже выше писалось — серьезный апгрейд произошел при понимании тупиковости ветви развития.
Повторю вопрос. Что с клиентской частью для IPad? JS образца 1997 года? JAVA? Что-то новое и нативное, написанное с нуля?
С нуля, конечно, до этого мобильных приложений у них не было вообще, была только веб-морда — то есть это по сути дела новый продукт, тут эволюционировать не с чего было. Просто в плохом случае (например, если бы ранее страницы генерились шаблонизатором на сервере, и не было никакого REST для SPA) для организации взаимодействия этого нового мобильного приложения с сервером пришлось бы перепахать немалую долю серверной части. Об этом я и говорю уже три комментария подряд.
Ваш пример про то, что иногда жирные приложения не влезают в пропускную способность сети.
Нет, об этом был пример сильно раньше — когда при резком возрастании нагрузки в 10 раз, можно легко отмасштабировать систему в 10 раз просто запустив 9 новых серверов. А если заранее подобное дело не предусмотреть, то потом может быть очень и очень больно. Это к вопросу об архитектуре.
Да и серверами все это не ограничивается. В десктопной разработке переход от MFC к WinForms/WPF и разным там Electron тоже не на один десяток лет растянулся. И MS Office, Photoshop, Autocad, 3dsMax, и многий другой софт никто не бросается переписывать с нуля — он нужен именно в таком виде, и он успешно продается. Да, все компании экспериментируют с новыми технологиями (у многих уже появились веб-версии), но существующие решения никто не снимает с поддержки и не прекращает их развитие.
С нуля, конечно, до этого мобильных приложений у них не было вообще, была только веб-морда — то есть это по сути дела новый продукт, тут эволюционировать не с чего было
Вот именно. С нуля. Хотя могли бы использовать что-то вроде electron и сделать приложение из сайта.
Об этом и речь — что в некоторых областях лучше с нуля, чем с наворачивать слои совместимости. Точнее — не совсем с нуля — остается know how, остаются библиотеки.
существующие решения никто не снимает с поддержки и не прекращает их развитие.
Что, правда??? Вашими устами да мед пить. Ну найдите мне процессор или чипсет с гарантированным сроком выпуска или поддержки в 20 лет. Или смартфон, на который 20 лет будут обновления приходить. Такие есть, но это очень нишевый сегмент.
Иногда целые направления вымирают. У меня — клавиатурный смартфон. Мало того, что он не поддерживается, так и замены никакой нет.
А уж дешевые смартфоны… Они вообще без поддержки. То есть выпуск запчастей — просто не предусмотрен, обновление прошивки — тоже.
Так что вот вам целая область, где обновления не тянут.
Вот именно. С нуля. Хотя могли бы использовать что-то вроде electron и сделать приложение из сайта.
Не хочу вас расстраивать, но Electron не работает на iPad, он тут вообще не в тему. Самым ближним по смыслу тут будет Cordova, но это получится только «сайт запиханный в браузер в виде приложения», что, мягко говоря, отличается от нормального мобильного клиента.
Что, правда??? Вашими устами да мед пить. Ну найдите мне процессор или чипсет с гарантированным сроком выпуска или поддержки в 20 лет.
Разговор про софт, хватит уже постоянно в сторону железа скатываться.
Примеры софта были выше, вполне конкретные, с названиями.
И даже касательно выхода новых чипсетов — при портировании на новую аппаратную платформу или процессорную архитектуру, то же ядро Linux не переписывают полностью с нуля, а адаптируют только отдельные его части.
У Android кстати, трудности с обновлениями как раз-таки обуславливаются непродуманной архитектурой системы, но движение к долговременной поддержке и обновлениям тоже есть, посмотрите Project Treble (https://source.android.com/devices/architecture/treble).
Разговор про софт, хватит уже постоянно в сторону железа скатываться.
В 98% процессоров софт — лишь приложение к железу. Оглянитесь вокруг, процессоров море. В часах, в микроволновке, в стиралке, в пылесосе, в телефонах, роутерах, лифтах… И лишь малая часть — в компьютерах.
Разговор начался со смены клиентского железа (софт для телевизора) и так и идет вокруг железа.
ядро Linux не переписывают полностью с нуля, а адаптируют только отдельные его части
Ох! И опять — вашими устами да мед пить. Постоянная беда — то одну подсистему переписали, то другую. Было конфигурирование платы кодом — ввели device tree. Подсистему wi-fi раза 2-3 переписывали. Был ifconfig — ввели ip2… Ну в общем как новая плата — так переделка хотя бы одной подсистемы в linux. Ну и, соответственно, в прикладном софте железки.
У Android кстати, трудности с обновлениями как раз-таки обуславливаются непродуманной архитектурой системы
По секрету — у мобильников без Android с обновлениями все ещё хуже. Как и у других железок. Телефон (не смартфон) хоть раз обновляли? Часы? Микроволновку? Стиралку?
Наша серверная часть (GPS, ГЛОНАСС) тоже обновляется раз в 5-10 лет. Выработал ресурс спутник, ушел с орбиты — запустили новый, с обновленным софтом.
На досуге почитайте, к чему приводит такой подход в АСУТП.
Но быть инженером и уметь решать инженерные задачи — нужно обязательно.
Простой пример: разработчик делает часть web-SCADA-системы для энергетики/транспорта/нефтедобычи, его текущей задачей является через REST API или WebSockets получать с сервера JSON-данные с состоянием процесса (которые изначально сгенерировались из OPC) и с помощью MVVM-фреймворка и библиотеки виджетов рендерить и обновлять мнемосхему технологического процесса.
Нужно ли ему для этого знать алгоритм анализа отказа электрозадвижки или разницу между кориолисовым и ультразвуковым расходомером?
Если у вас локалка — можно ничего не знать. А вот если GPRS… В районе Сочи за пару лет до олимпиады в час пик пакеты по GPRS шли раз в 20 минут.
При нормальной работе SCADA многие датчики обновляются почти синхронно. Открыли задвижку — уменьшилось давление. Подали ток — зажглась лампочка. Отличия на пару мс возникают из-за несинхронности циклов опроса датчиков и оператору не видны.
А вот когда у нас паузы в обмене от долей секунды и больше, эту проблему надо решать. Иначе или операторов хватит инфаркт или они прозевают реальную аварию.
Одно из решений — это понимая технологическую логику, объединить группы элементов и изменять их состояние или синхронно или тогда, когда после изменения одного из членов группы прошло не мене 100 мс объектового времени.
Но для такого решения нужно прилично понимать технологическую логику.
При нормальной работе SCADA многие датчики обновляются почти синхронно. Открыли задвижку — уменьшилось давление. Подали ток — зажглась лампочка. Отличия на пару мс возникают из-за несинхронности циклов опроса датчиков и оператору не видны.
А вот когда у нас паузы в обмене от долей секунды и больше, эту проблему надо решать. Иначе или операторов хватит инфаркт или они прозевают реальную аварию.
Одно из решений — это понимая технологическую логику, объединить группы элементов и изменять их состояние или синхронно или тогда, когда после изменения одного из членов группы прошло не мене 100 мс объектового времени.
Но для такого решения нужно прилично понимать технологическую логику.
Кстати, с языками пример вы хороший привели. Только вопрос должен звучать так:
«Сможете ли вы успешно начать работать в компании, в которой приняты ежедневные созвоны с иностранными заказчиками, если до этого вы изучали английский язык только по учебникам, но ни разу не говорили на нем с живым человеком?»
«Сможете ли вы успешно начать работать в компании, в которой приняты ежедневные созвоны с иностранными заказчиками, если до этого вы изучали английский язык только по учебникам, но ни разу не говорили на нем с живым человеком?»
Опыт показывает, что как раз я — могу. Люди со словарным запасом в 100 раз больше — не могут.
А вот вам обратный пример. Китаянка, лет 10 в России, победитель конкурса русского романса имени Изабеллы Юрьевой. И мне пришлось объяснять ей, что такое совершенная форма глагола. За 10 лет практики — не поняла. Потребовалось полчаса теории — и она нашла эквивалент в китайском и поняла отличия.
А вот вам обратный пример. Китаянка, лет 10 в России, победитель конкурса русского романса имени Изабеллы Юрьевой. И мне пришлось объяснять ей, что такое совершенная форма глагола. За 10 лет практики — не поняла. Потребовалось полчаса теории — и она нашла эквивалент в китайском и поняла отличия.
Конечно. И чтобы закончить институт и аспирантуру и защитить кандидатскую в России — тоже. Просто ей самой захотелось лучше говорить на русском. И оказалось что 10 лет практики дают меньше, чем немного теории.
А зачем ей нужно было это самое понятие совершенной формы глагола?
Ли Вон Яна читали? Ну вот при перепутывании совершенной и несовершенной формы похоже получается. Все-таки «я делал задание» и «я сделал задание» имеют разный смысл. А отличаются они именно верным выбором совершенной и несовершенной формы.
А, то есть, общаться она не могла? Ну, тогда да, как сказал staticlab, для пения действительно не обязательно понимать смысл.
А русский (или иной родной для вас) язык вы, кстати, по учебникам учили или по общению с живыми людьми?
Я, кстати, по приезду в англоязычные страны понял, что моих знаний английского совершенно недостаточно, чтобы успешно общаться с людьми в реальной жизни. Хотя 8.5 баллов в IELTS.
Общаться могла — она лет 10 училась на русском языке сначала в ВУЗе, потом в аспирантуре.
Давно с живыми детьми общались? Говорить грамотной литературной речью они начинают лет в 10-12. Использование причастны и деепричастных оборотов приходит ещё позже (а у дебилов) не приходит. И это при том, что лет с 4х — начинается изучение родного языка по учебникам. Сначала — в садике, потом в школе.
Хотите тратить 15-20 лет на изучение — языка, тогда да, изучайте как дети, на практике.
Хотя… интересный момент, если ребенок не изучает русский язык в школе, появятся ли у него в речи деепричастные обороты? Ну или не в школе, но по учебнику.
Между прочим, если специально не вслушиваться — то отсутствие деепричастных оборотов и сложноподчиненных фраз незаметно. Зато если вслушиваться — то легко можно отличить дебилов.
А чтобы общаться — хорошего знания языка не нужно. Ребенок в полтора года вполне общается. Жесты, мимика, отдельные глаголы — для понимания этого хватает. Ровно так же я общался на иврите с израильтянином при моем словарном запасе в сотню слов. Ничего, друг друга поняли.
P.S. Дебил — это не ругательство, а олигофрения в стадии дебильности. См. «Форест гамп», но Гамп — имбецил, а не дебил. Помните «а потом я прикупил акции какой-то яблочной компании»?
Примеры реальных ошибок
Очень приятно с вами познакомилась!
Я долго не ответила твое сообшение.
Если я ошибалась и спросила как правильно говорить, они мне скажут.
Я долго не ответила твое сообшение.
Если я ошибалась и спросила как правильно говорить, они мне скажут.
А русский (или иной родной для вас) язык вы, кстати, по учебникам учили или по общению с живыми людьми?
Давно с живыми детьми общались? Говорить грамотной литературной речью они начинают лет в 10-12. Использование причастны и деепричастных оборотов приходит ещё позже (а у дебилов) не приходит. И это при том, что лет с 4х — начинается изучение родного языка по учебникам. Сначала — в садике, потом в школе.
Хотите тратить 15-20 лет на изучение — языка, тогда да, изучайте как дети, на практике.
Хотя… интересный момент, если ребенок не изучает русский язык в школе, появятся ли у него в речи деепричастные обороты? Ну или не в школе, но по учебнику.
Между прочим, если специально не вслушиваться — то отсутствие деепричастных оборотов и сложноподчиненных фраз незаметно. Зато если вслушиваться — то легко можно отличить дебилов.
А чтобы общаться — хорошего знания языка не нужно. Ребенок в полтора года вполне общается. Жесты, мимика, отдельные глаголы — для понимания этого хватает. Ровно так же я общался на иврите с израильтянином при моем словарном запасе в сотню слов. Ничего, друг друга поняли.
P.S. Дебил — это не ругательство, а олигофрения в стадии дебильности. См. «Форест гамп», но Гамп — имбецил, а не дебил. Помните «а потом я прикупил акции какой-то яблочной компании»?
Общаться могла — она лет 10 училась на русском языке сначала в ВУЗе, потом в аспирантуре.
Я имел в виду, что без подобных ошибок, зря не дописал.
Давно с живыми детьми общались? Говорить грамотной литературной речью они начинают лет в 10-12. Использование причастны и деепричастных оборотов приходит ещё позже (а у дебилов) не приходит.
ЧСХ у тех, кто много читает (художественные книги, не учебники), оно как-то само приходит. Мозг всё-таки заточен под то, чтобы выделять закономерности, а живой человеческий язык создан такими же людьми.
Я грамотно писал и расставлял запятые-тире и до всяких учебников и старших классов школы, потому что в детстве читал очень много худлита. А последние лет десять я худлит почти не читаю, к сожалению, последние года три живу в нерусскоязычных странах, и падение грамотности, стилистические корявости, появление сомнений в тех случаях, в которых их раньше не было, и так далее, лично мне видно невооружённым глазом.
Хотите тратить 15-20 лет на изучение — языка, тогда да, изучайте как дети, на практике.
Зачем 15-20? Можно быстрее, если погружаться в среду и как-то эффективно это время тратить.
Вы всерьёз собираетесь запомнить правила и потом в реальной жизни «так, тут я собираюсь сказать о том, что тогда могло бы происходить в тот момент, но не случилось, значит, надо воспользоваться хрен-его-знает-как-называющимся временем и сказать I would have been sleeping...» и вроде того? В переписке это ещё, возможно, сойдёт, но риалтайм-беседу вы так поддерживать не сможете. Это должно как-то интуитивно появиться, на уровне чувства языка, с практикой.
Или вот какой учебник вам расскажет, что в разговорной речи past simple используют просто так, а present perfect — когда хотят сакцентировать на этом внимание? Поэтому когда вы приходите домой, а жена вам говорит «I bought some food», вы можете сказать «OK» и пойти дальше, а если она говорит «I have bought some food», то надо её похвалить и погладить по голове, потому что она, вероятно, этого ожидает?
если людям надо что-то у вас узнать, они будут вас слушать, несмотря на скудный словарный запас или произношение. они могут про себя плеваться, ругаться и проклинать вас — но если вы в состоянии донести до них нужные данные, а другие не могут — выхода нет. Я общался с китайскими инженерами на одной из выставок MIPS, их английский был хуже моего. Но стоящая рядом девушка-переводчик из их группы хоть и говорила намного лучше, но ни черта не понимала в терминах (вообще косяк конечно, такую с собой брать — но, может не было других)
из своего опыта — я спокойно веду переписку на английском, но мне некомфортно на нем говорить, потому что сомневаюсь в произношении. почитать что-то, посмотреть что-то в оригинале — получается. а для разговора нужна практика, поэтому в планах найти свободное время для голосового общения с native speaker, и никакая теория тут не заменит такой опыт
а в вашем примере — если за полчаса теории она это поняла, то скорее всего, раньше просто не задумывалась о совершенной форме. для точного понимания неплохо бы знать контекст, как вы это ей объясняли. все таки «а как у вас образуется совершенная форма глагола» — это одно, а «слушай, а почему иногда это слово пишется делал, а иногда — сделал, никак не могу понять в чем разница» — это другое. к тому же, многие исполнители не знают языка, на котором они поют. заучивают интонации и произношение и всё.
из своего опыта — я спокойно веду переписку на английском, но мне некомфортно на нем говорить, потому что сомневаюсь в произношении. почитать что-то, посмотреть что-то в оригинале — получается. а для разговора нужна практика, поэтому в планах найти свободное время для голосового общения с native speaker, и никакая теория тут не заменит такой опыт
а в вашем примере — если за полчаса теории она это поняла, то скорее всего, раньше просто не задумывалась о совершенной форме. для точного понимания неплохо бы знать контекст, как вы это ей объясняли. все таки «а как у вас образуется совершенная форма глагола» — это одно, а «слушай, а почему иногда это слово пишется делал, а иногда — сделал, никак не могу понять в чем разница» — это другое. к тому же, многие исполнители не знают языка, на котором они поют. заучивают интонации и произношение и всё.
Объяснял примерно так
«Очень приятно с вами познакомилась!»
«познакомиЛАСЬ» — что СДЕлала. То есть знакомство УЖЕ состоялось. Но эта фраза говорится ВО ВРЕМЯ знакомства, потому там говорится «познакомиТЬСЯ» (что ДЕлать, а не что уже СДЕлано). Причём форма «приятно познакомиться» настолько устйочивая, что все другие варианты звучат не по-русски. То есть просто «познакомилась» сказать можно, а со слово «приятно» — только форма «познакомиться».
Привыкай, в русском много необъяснимых и малообъяснимых финтов ушами. Мы едем В Китай, но НА Украину. :) И почему так — никто не знает. :)
«познакомиЛАСЬ» — что СДЕлала. То есть знакомство УЖЕ состоялось. Но эта фраза говорится ВО ВРЕМЯ знакомства, потому там говорится «познакомиТЬСЯ» (что ДЕлать, а не что уже СДЕлано). Причём форма «приятно познакомиться» настолько устйочивая, что все другие варианты звучат не по-русски. То есть просто «познакомилась» сказать можно, а со слово «приятно» — только форма «познакомиться».
Привыкай, в русском много необъяснимых и малообъяснимых финтов ушами. Мы едем В Китай, но НА Украину. :) И почему так — никто не знает. :)
После пятого объяснения она нашла эквивалент в китайском языке и все стало просто.
Не думаю, что можно закончить институт, аспирантуру и защитить кандидатскую в России «заучивая интонации и произношение». Просто 10 лет общения на русском не заменяют целенаправленное изучение, даже с таким дурным преподавателем, как я.
насчет приятно познакомиться
не хочется лезть в умные источники, превращаться в зануду и искать грамотное объяснение, своими словами — довольно простой способ объяснять нюансы использования глаголов подставляя что-то типа модальных глаголов. в данном контексте это будет — приятно было познакомиться — лучше ощущается отстраненность действия от говорящего
приятно познакомилась — тут никакой глагол не влезет, зато напрашивается указание на объект:
я/ты/кошка/страна приятно познакомилась
и получается, что в 1м варианте смысловой упор на то, факт совершения действия, и эта форма стала устоявшимся выражением
а во 2м — акцент на кто-то-там совершил какое-то действие — упор или на само действие, или на кого-то-там
абстрагируясь от общепринятых выражений, можно сравнить:
круто покататься на велосипеде
круто покатался на велосипеде
хотя и мое объяснение кривовато, но пусть уж будет.
хорошо, что нашелся аналог в китайском, я думаю, это сыграло ключевую роль
приятно познакомилась — тут никакой глагол не влезет, зато напрашивается указание на объект:
я/ты/кошка/страна приятно познакомилась
и получается, что в 1м варианте смысловой упор на то, факт совершения действия, и эта форма стала устоявшимся выражением
а во 2м — акцент на кто-то-там совершил какое-то действие — упор или на само действие, или на кого-то-там
абстрагируясь от общепринятых выражений, можно сравнить:
круто покататься на велосипеде
круто покатался на велосипеде
хотя и мое объяснение кривовато, но пусть уж будет.
хорошо, что нашелся аналог в китайском, я думаю, это сыграло ключевую роль
я попытался осилить эту ветку теория vs. практика, но надоело
как человек, давно старающийся избегать категоричности и искать компромиссы и золотую середину, хотел бы сказать
важны не отдельно теория, и не отдельно практика, важен их баланс
правильные пропорции, в свою очередь, надо подбирать исходя из целей и возможностей. Например, если надо уметь считать определенные задачи — то приоритет на практику именно решения и именно этих задач. если надо не просто считать, но и уметь найти другой способ решения — то теория вам пригодится больше.
поэтому, я считаю, что тут можно бесконечно дискутировать — универсального решения нет и каждый должен сам для себя выбирать
хорошо, что нашелся аналог в китайском, я думаю, это сыграло ключевую роль
А в любом естественном языке есть признак завершенности действия, независимо от того, рассматривается он в школьном курсе или нет.
Модальные глаголы и артикли не проходят в курсе русского языка. Тем не менее в русском был артикль «сей» и есть модальные глаголы (те, что управляют другим глаголом — надо/хочу/могу кушать).
важны не отдельно теория, и не отдельно практика, важен их баланс правильные пропорции, в свою очередь, надо подбирать исходя из целей и возможностей.
Это общие слова, они не учитывают экономику. А экономика в том, что новый язык учится по учебнику дома, а дальше практика — уже на рабочем месте. И практика — только после изучения учебника «от корки до корки». Иное приводит к методу тыка и недочитыванию учебника до конца.
если учитывать экономику и рациональность, то надо рассматривать и цели. незачем сразу учить язык полностью, если не собираешься использовать все эти знания. ну, точнее, учить можно, хуже от этого не будет, но зачем? выучил в объеме, достаточном для уверенного практического применения — применяешь — параллельно продолжаешь учить — по мере накопления знаний усложняешь уровень своих задач — и так пока не упрешься в потолок
Для уверенного практического применения языка программирования — нужен весь язык. Ну или почти весь — тот же Delphi просто не реализовывал полный Паскаль, а писать на Си можно не зная триграфов.
Дальше идет стадия изучения приемов программирования и она чем дальше — тем более языконезависимая. Обход дерева — это обход дерева, на каком языке его не пиши. И вот на этой стадии — уже нужен компилятор.
Каждый новый язык дает новые парадигмы, которые помогают писать на привычных языках.
Ну как пример… программисты на С++ обычно не понимают, что аппаратные исключения можно обрабатывать. Хотя Visual Studio и дает такую возможность. А для Delphi — это норма.
Ещё пример. Мы привыкли, что переменная — это ячейка памяти, куда можно много раз класть разные значения. Но есть язык, где переменная — это имя для значения. И присваивать переменой можно только один раз.
Дальше идет стадия изучения приемов программирования и она чем дальше — тем более языконезависимая. Обход дерева — это обход дерева, на каком языке его не пиши. И вот на этой стадии — уже нужен компилятор.
учить можно, хуже от этого не будет, но зачем?
Каждый новый язык дает новые парадигмы, которые помогают писать на привычных языках.
Ну как пример… программисты на С++ обычно не понимают, что аппаратные исключения можно обрабатывать. Хотя Visual Studio и дает такую возможность. А для Delphi — это норма.
Ещё пример. Мы привыкли, что переменная — это ячейка памяти, куда можно много раз класть разные значения. Но есть язык, где переменная — это имя для значения. И присваивать переменой можно только один раз.
все ваши слова верны, если считать, что написание кода — это всегда задача, требующая высокой квалификации. сейчас — нет. сейчас есть потребность в людях, которые в состоянии написать какие-то простые вещи и чтоб они работали. к сожалению, я осознаю, что в разработке пока еще нуб, поэтому приведу пример из более близкой мне области:
есть задача — организовать видеонаблюдение на объекте.
было бы круто, чтобы в моей команде трудились только высококлассные профи, но это экономически невыгодно. поэтому, на практике это будет примерно так:
1. прокладка кабеля — тут мне нужны дешевые работники. они могут не знать, для чего этот кабель и какие его характеристики. чтобы они не проложили внутренний кабель по улице, им говорят — вот этот кабель тянете здесь, другой кабель тянете там. всё, что от них надо — уметь класть ровную красивую трассу.
2. установка оборудования. просто чтото прикрутить могут и предыдущие ребята, но чаще надо и прикручивать, и как минимум провода развести-подключить. поэтому сюда подбираются ребята с более глубокими знаниями и опытом. которые в состоянии на нескольких квадратных метрах стены выбрать точку для монтажа камеры, чтобы обеспечивался нужный вид, качественно обжать rj45 или припаять BNC, выбрать оптимальный тип крепежа под ту или иную поверхность и т.п. вобщем, когда вариант «берем таджиков и стоим у них над душой контролируем чтоб не косячили» будет дороже и/или неудобнее, чем сразу делегировать эти задачи более подготовленным людям.
3. пусконаладка. здесь нужны инженеры — выставить все параметры оборудования, провести обучение персонала заказчика и т.п.
все эти люди занимаются «установкой видеонаблюдения». при этом у них у всех разная квалификация.
можно загрузить людей и п.1 информацией про виды кабеля для тех или иных условий, объяснить ттх оборудования, научить настраивать. собственно, молодые ребята в основном так и начинают — приходят прокладывать кабель и в процессе учатся всему остальному. но кто-то остается в рамках своих текущих знаний, и ему этого достаточно. естественно, кто-то напирает на теорию и приходит устраиваться сразу инженером. и я не могу сказать, что чей-то подход плохой. если этот подход позволяет добиться поставленных целей — он работает.
если все разработчики будут высококвалифицированные, то кто тогда будет писать те же парсеры на php за 300р?
по-хорошему, я сам пытаюсь комбинировать и практику, и теорию — потому что семью надо кормить, и я был бы рад, если бы моя теоретическая база была глубже. потому что у меня в планах — научиться разрабатывать что-то интересное и серьезное. а были бы скромные планы, то и поверхностных познаний хватило бы
есть задача — организовать видеонаблюдение на объекте.
было бы круто, чтобы в моей команде трудились только высококлассные профи, но это экономически невыгодно. поэтому, на практике это будет примерно так:
1. прокладка кабеля — тут мне нужны дешевые работники. они могут не знать, для чего этот кабель и какие его характеристики. чтобы они не проложили внутренний кабель по улице, им говорят — вот этот кабель тянете здесь, другой кабель тянете там. всё, что от них надо — уметь класть ровную красивую трассу.
2. установка оборудования. просто чтото прикрутить могут и предыдущие ребята, но чаще надо и прикручивать, и как минимум провода развести-подключить. поэтому сюда подбираются ребята с более глубокими знаниями и опытом. которые в состоянии на нескольких квадратных метрах стены выбрать точку для монтажа камеры, чтобы обеспечивался нужный вид, качественно обжать rj45 или припаять BNC, выбрать оптимальный тип крепежа под ту или иную поверхность и т.п. вобщем, когда вариант «берем таджиков и стоим у них над душой контролируем чтоб не косячили» будет дороже и/или неудобнее, чем сразу делегировать эти задачи более подготовленным людям.
3. пусконаладка. здесь нужны инженеры — выставить все параметры оборудования, провести обучение персонала заказчика и т.п.
все эти люди занимаются «установкой видеонаблюдения». при этом у них у всех разная квалификация.
можно загрузить людей и п.1 информацией про виды кабеля для тех или иных условий, объяснить ттх оборудования, научить настраивать. собственно, молодые ребята в основном так и начинают — приходят прокладывать кабель и в процессе учатся всему остальному. но кто-то остается в рамках своих текущих знаний, и ему этого достаточно. естественно, кто-то напирает на теорию и приходит устраиваться сразу инженером. и я не могу сказать, что чей-то подход плохой. если этот подход позволяет добиться поставленных целей — он работает.
если все разработчики будут высококвалифицированные, то кто тогда будет писать те же парсеры на php за 300р?
по-хорошему, я сам пытаюсь комбинировать и практику, и теорию — потому что семью надо кормить, и я был бы рад, если бы моя теоретическая база была глубже. потому что у меня в планах — научиться разрабатывать что-то интересное и серьезное. а были бы скромные планы, то и поверхностных познаний хватило бы
все ваши слова верны, если считать, что написание кода — это всегда задача, требующая высокой квалификации.
Наверное — это национальная черта характера. Если уж не получается быть в первым в мире, то хоть первым в городе. Не получается в городе — так хоть в деревне.
если все разработчики будут высококвалифицированные, то кто тогда будет писать те же парсеры на php за 300р?
Высококвалифицированные разработчики за день. Или за полдня.
сейчас есть потребность в людях, которые в состоянии написать какие-то простые вещи и чтоб они работали.
И много хороших вакансий? :-))) И как платят, прилично? :-)
Наверное — это национальная черта характера. Если уж не получается быть в первым в мире, то хоть первым в городе. Не получается в городе — так хоть в деревне.
это же хорошо. но не забывайте, что есть куда больше людей без амбиций
Высококвалифицированные разработчики за день. Или за полдня.
триста рублей — вы или шутите, или сумму не так прочитали, или считаете, что эта работа будет стоить столько, сколько платят высококвалифицированному разработчику за полдня(не будет точно. эту нишу сразу займут те, кто готов это делать намного дешевле, и знания у них будут очень поверхностные, только чтобы задачу решить)
И много хороших вакансий? :-))) И как платят, прилично? :-)
а никто и не говорит, что они хорошие. и платят там наверняка не очень прилично (из личного опыта — есть несколько знакомых, которые пишут на PHP за 40-50т.р./мес, и их устраивает на фоне средней зп по городу около 25т.р.( не Москва))
есть спрос на разработчиков с не сильно выдающимися навыками. и есть предложение. это может не касаться вас, не касаться меня, но оно все равно есть
есть куда больше людей без амбиций
Без амбиций можно и дворником работать. Или в котельной — как Цой.
триста рублей — вы или шутите, или сумму не так прочитали
«Мы не настолько богаты, чтобы покупать дешевые вещи». К этим 300 рублям добавьте работу тестеров и менеджера. И время на правку багов, которые вылезут при эксплуатации. Выйдет дороже, чем день работы сеньора, который сразу сделает нормально.
Вот вам задачка. Две компании, два админа. Первый — каждый день на работе, все время занят, иногда ночами сидит. Второй — приезжает на работу раз в месяц за зарплатой. Причем зарплата у него — раз в 10 больше, чем у первого. Кто из них выгодней?
Второй. Ибо цена часа простоя — как зарплата второго админа за 10 лет.
есть спрос на разработчиков с не сильно выдающимися навыками. и есть предложение.
Пока ещё есть. Дальше почти вся такая работа будет забангалорена.
прямой связи между профессией и амбициями нет.
дворником тоже можно быть с амбициями, я лет 7 назад даже читал про парня, который какое-то рекордное количество участков на себя взял, и ему это было в кайф
какой тестер, какой менеджер, о чем вы? любой сайт фриланса, и, предположу, небольшая фирма — вот тебе простая задача, оплата по факту выполнения. написал за час — молодец, получи деньги. не работает? ну или сиди ищи где накосячил, или давайдосвиданья, ищем другого исполнителя (в случае фриланса)
и пример про админов — все верно, если час простоя стоит столько. а если день простоя для небольшой фирмы некритичен — то выгодней будет студент, который за ночь всё починит, а денег возьмет копейки
на международных биржах фриланса на каждую простую задачу за час налетает 20-30 индусов или пакистанцев и демпингуют. это нормально, это уже есть, и люди с ними работают.
мне очень интересно, вы в реальный мир давно выглядывали последний раз? там прекрасно уживаются множество комбинаций зарплат и навыков, а ваши примеры они красивые, но уж больно теоретические и применимы к большим компаниям. а в маленьких зачастую бардак, но этот бардак оправдывается простотой и дешевизной. вспомните пресловутый треугольник «быстро, качественно, дешево — можно выбрать 2 параметра из 3х». сочетание быстро и дешево очень популярно.
дворником тоже можно быть с амбициями, я лет 7 назад даже читал про парня, который какое-то рекордное количество участков на себя взял, и ему это было в кайф
какой тестер, какой менеджер, о чем вы? любой сайт фриланса, и, предположу, небольшая фирма — вот тебе простая задача, оплата по факту выполнения. написал за час — молодец, получи деньги. не работает? ну или сиди ищи где накосячил, или давайдосвиданья, ищем другого исполнителя (в случае фриланса)
и пример про админов — все верно, если час простоя стоит столько. а если день простоя для небольшой фирмы некритичен — то выгодней будет студент, который за ночь всё починит, а денег возьмет копейки
на международных биржах фриланса на каждую простую задачу за час налетает 20-30 индусов или пакистанцев и демпингуют. это нормально, это уже есть, и люди с ними работают.
мне очень интересно, вы в реальный мир давно выглядывали последний раз? там прекрасно уживаются множество комбинаций зарплат и навыков, а ваши примеры они красивые, но уж больно теоретические и применимы к большим компаниям. а в маленьких зачастую бардак, но этот бардак оправдывается простотой и дешевизной. вспомните пресловутый треугольник «быстро, качественно, дешево — можно выбрать 2 параметра из 3х». сочетание быстро и дешево очень популярно.
какой тестер, какой менеджер, о чем вы?
О том, что зачем за 300 рублей писать парсер? Взял тестовый пример, глазками распарсил, результаты захардкодил, код обсфуцировал. На тестовом примере — работает, деньги взял и ушел. А чтобы уговорить доделать — нужен менеджер. И чтобы понять, что там фуфло — нужен тестер. Ну или менеджер в роли тестера.
Ну в общем почитайте про то, что у 9 беременных женщин ребенок через месяц не родится (в первом русском издании — "Как проектируются и создаются программные комплексы".).
сочетание быстро и дешево очень популярно.
Угу, но… вы собрались жить на те деньги, что платят индусам? Или вы рассчитываете на простаков, которые не знают про индусов и международные биржи?
Взял тестовый пример, глазками распарсил, результаты захардкодил, код обсфуцировал
И уже после этапа «код обфусцировал» и «работает только на тестовом примере» получаешь комплейн, остаешься без денег и теряешь репутацию (что прямо влияет на дальнейшие предложения о работе).
А это единственная стратегия, как зарабатывать на 300 рублевых заказах. Создал кучу аккаунтов — и впарил туфту по 300 рублей куче заказчиков. Да, нечестно, зато выгодно.
А про репутацию — смешно. Разработчик с репутацией и 300 рублей за несколько дней работы? Ну не смешите.
А про репутацию — смешно. Разработчик с репутацией и 300 рублей за несколько дней работы? Ну не смешите.
Вариант «создал кучу аккаунтов» не пройдет. На хоть сколь-нибудь приличных сервисах идет верификация по паспорту и видео обычно.
300 рублей можно заменить на 5000 рублей и даже 15000 рублей — смысл сильно не поменяется, механизм тот же самый.
300 рублей можно заменить на 5000 рублей и даже 15000 рублей — смысл сильно не поменяется, механизм тот же самый.
а где было написано что 300 рублей за несколько дней? 300 рублей это 5$ — как раз минимальная часовая ставка на многих фриланс-биржах.
Итого, работая по 5 часов в день (остальное время занимает поиск заказов, согласование задания и прокрастинация), при 20 дневной рабочей недели человек будет зарабатывать около 30 т.р. в месяц, что для многих российских регионов уже очень хорошая зарплата. И это только минимальная ставка — с ростом рейтинга (той самой «репутации») и расширения портфолио, рейт будет расти, и эти суммы смело умножаются в несколько раз.
Итого, работая по 5 часов в день (остальное время занимает поиск заказов, согласование задания и прокрастинация), при 20 дневной рабочей недели человек будет зарабатывать около 30 т.р. в месяц, что для многих российских регионов уже очень хорошая зарплата. И это только минимальная ставка — с ростом рейтинга (той самой «репутации») и расширения портфолио, рейт будет расти, и эти суммы смело умножаются в несколько раз.
Написано было тут:
5$ в час — нормальные деньги для студента, мамы, сидящей с младенцем, или как приработок. Тут я согласен с вами.
А вот 5$ за весь проект — это совсем иная стратегия заработка, основанная на обмане заказчика.
если все разработчики будут высококвалифицированные, то кто тогда будет писать те же парсеры на php за 300р? 5$ в час — нормальные деньги для студента, мамы, сидящей с младенцем, или как приработок. Тут я согласен с вами.
А вот 5$ за весь проект — это совсем иная стратегия заработка, основанная на обмане заказчика.
О том, что зачем за 300 рублей писать парсер
опять же, это больше к фрилансу. выложили задание — спарсить какой-нибудь интернет магазин.
хочешь — делай, хочешь — нет. обычно желающие есть.
и нет никакого тестового примера. есть ссылка на сайт. нет никакого тестера — заказчик смотрит, если результат его устраивает — держи оплату. если нет — и оплаты нет.
вы собрались жить на те деньги, что платят индусам
я нет. но большая часть страны живет на примерно такие же деньги, а то и меньше. из статьи про тот же бангалор, в переводе на рубли там средняя зп 30к+. для многих это уже хорошая зарплата
Или вы рассчитываете на простаков, которые не знают про индусов и международные биржи?
чтобы работать на международных биржах и с индусами нужно знать английский. это отсеивает многих.
снимите розовые очки, огромная часть рынка — это заказчики с простыми задачами, и разработчики с невысокой квалификацией, готовые работать за предлагаемые суммы. вы можете не знать про них, не рассматривать всерьез, они могут вам не нравится — но они всё равно есть и будут. в эту нишу даже индусы не зайдут. оплата сопоставимая с тем, что у них есть, или ниже, но еще и русский надо учить
я нет. но большая часть страны живет на примерно такие же деньги, а то и меньше
Программист, работающий за 10К рублей??? Не школьник, не домохозяйка с тремя детьми, не дворник, подрабатывающий программированием, а именно программист на full-time? Не верю. Тот же рерайтинг/копирайтинг дает больше заработка.
Без амбиций можно и дворником работать. Или в котельной — как Цой.
Зачем бросаться в крайности? Мир не чёрно-белый, есть и другие варианты. Не всем быть космонавтами, и не всем этого хочется.
«Мы не настолько богаты, чтобы покупать дешевые вещи». К этим 300 рублям добавьте работу тестеров и менеджера. И время на правку багов, которые вылезут при эксплуатации. Выйдет дороже, чем день работы сеньора, который сразу сделает нормально.
Одна знакомая мне фирма заказала относительно крупный проект у вот такого сеньора с огромным опытом и, соответственно, требованиями к зарплате (порядка 150$ в час). Менеджмент наивно положился на известность, крутость, опыт, ответственность и т.д., и не привлекла к составлению требований своих технических специалистов. В результате проект после сдачи допиливается уже год (или больше), естественно, за дополнительные деньги. Например, везде, где используется SQL, были допущены инъекции. На одной из встреч, на которой уже присутствовали местные программисты, на вопрос о безопасности был получен лаконичный ответ: этого не было в требованиях. Вот вам и сеньор...
А вообще, независимо от этого конкретного случая, в том же Израиле рынок забит требованиями микроразработок для всевозможных CMS или того же Magento — на PHP. И я знаком с преуспевающими фрилансерами, берущими порядка 50$ в час, клиенты которых успешно пишут свои блоги, имеют успешные веб-магазины, заточенные под нужды бизнеса. И для выполнения этой работы не нужно даже намёка на высшее образование, только интуитивное логическое мышление и хорошее знакомство с поддерживаемым CMS.
Пока ещё есть. Дальше почти вся такая работа будет забангалорена.
Или не будет. Лично знаком с многими бизнесами, которые пытались радикально экономить, обращаясь к индусам, а потом, после мучительного ада из полувзаимонепонимания, шли на поклон к местным специалистам.
на вопрос о безопасности был получен лаконичный ответ: этого не было в требованиях. Вот вам и сеньор...
Нормальный инженерный подход. Тип — «делец». Дальше — идет торг о сумме, за которую будет вставлено недостающее.
И я знаком с преуспевающими фрилансерами, берущими порядка 50$ в час,
50$ в час — это 8200$ в месяц, то 474 труб в месяц. Извините, это далеко не миддл.
А речь шла 60 центах в час, то есть 300 рублей в день. И чем с таким фрилансом связываться — лучше уж забангалорить.
Высококвалифицированные разработчики за день. Или за полдня.
Квалифицированный разработчик решит задачу в 3 раза быстрее (с учетом тестирования, переделок, и т.д.), но и попросит в 3 раза больше денег. Эффективность в итоге примерно одинаковая, но разница в том, что квалифицированному разработчику можно будет давать сложные задачи, которые чайнику будут не по силам, и наоборот, простыми задачами ему будет заниматься скучно и неинтересно.
Поэтому спрос на джунов и мидлов никогда не пропадет.
И много хороших вакансий? :-))) И как платят, прилично? :-)
Развитие средств разработки, фреймворков, методологий, привело к тому что порог вхождения снизился. Теперь почти любой человек с улицы (при условии наличия логического мышления и усидчивости) может пройти несколько курсов по фронтенду на ютубе за пару месяцов, сделать парочку pet-проектов, устроиться на работу junior'ом, за 2-3 года дорасти до позиции middle'а и получать зарплату в несколько раз превышающую среднюю по региону (а на удаленке и того больше), а если захочет поменять работу — так его еще в десятки компаний с руками оторвут. При этом он не будет знать тонкостей ООП, не будет знать как интерпретатор компилирует его программу в байт-код, не будет знать как устроен TCP/IP, с помощью которого он шлет REST-запросы к серверу, но при этом он будет выдавать приемлемый по качеству продукт. В выигрыше тут все: люди не торгуют у прилавка и не крутят гайки на заводе, кодят за хорошую зарплату в уютном офисе с массажными креслами и свободным графиком (а зимой так вообще из домика на побережье моря где-нибудь в Таиланде), а бизнес получает в нужных количествах специалистов, способных решать его задачи.
Понятное дело, что люди, обладающие богатым разносторонним опытом или наоборот узкой, но ценной специализацией, «съевшие собаку» сотню раз и обладающие глубокими знаниями работу себе тоже всегда найдут и будут получать еще больше, но в реалиях бизнеса такие нужны не везде и не всегда.
Развитие средств разработки, фреймворков, методологий, привело к тому что порог вхождения снизился.
Судя по вашим предыдущим постам — для вас повысился, а не снизился. Я про "держать в голове тысячи методов стандартных библиотек и API платформы с точности до каждого символа, порядка и типов аргументов с учетом всех перегрузок функций".
Не нужно все это инженеру, есть справочники. А вот если ты не инженер, не программист, а просто тупой кодер — вот тогда зубрить API полезно.
Но в тонкостях работы кодеров я не разбираюсь. 30 лет работал инженером-программистом и так и помру инженером и программистом.
Судя по вашим текущим постам, вы не читаете вообще что вам пишут, или сознательно перевираете аргументы. Я как раз-таки писал, что не нужно держать в уме тысячи методов API, потому что хорошая IDE сама отлично работает в роли справочника.
Ну так сразу и говорите, что разбираетесь только в тонкостях работы в определенной сфере на определенных позициях, а о другом представления не имеете, но при этом категорично пытаетесь рассуждать и делать выводы.
Ну так сразу и говорите, что разбираетесь только в тонкостях работы в определенной сфере на определенных позициях, а о другом представления не имеете, но при этом категорично пытаетесь рассуждать и делать выводы.
Гм, вам IDE подсказывает название процедуры и особенности её применения? Или вам только порядок параметров нужен, а на особенности забивается болт?
Мне действительно не очень понятно, как можно делать систему, не разбираясь в том, что эта система будет делать. Вы бюджет пилите, что ли? Или пишите в стол?
Мне это все очень напоминает миниатюру Жванецкого про пуговицы.
Зарабатывать таким путем — можно. Получать удовольствие от работы — очень сложно.
Мне действительно не очень понятно, как можно делать систему, не разбираясь в том, что эта система будет делать. Вы бюджет пилите, что ли? Или пишите в стол?
Мне это все очень напоминает миниатюру Жванецкого про пуговицы.
Зарабатывать таким путем — можно. Получать удовольствие от работы — очень сложно.
Ну я, например, обычно не помню, в каком порядке в CreateFile нужно слать параметры. И не хочу этого запоминать, потому что есть IDE.
В целом же согласен, IDE не заменяет знания API.
В целом же согласен, IDE не заменяет знания API.
Гм, вам IDE подсказывает название процедуры и особенности её применения?
При наличии doxygen/javadoc/etc-комментариев или поддержки со стороны платформы — отлично показывает краткое описание, подробное описание, точное назначение и контракты входных и выходных параметров, свойства thread- и exception-safety и т.д.
Контекстная справка со времен турбо-паскаля известна, если не раньше. Собственно IDE для этого не нужен, в почти любом программируемом редакторе можно взять текущее слово под курсором и передать его внешней программе.
А вот динамически генерируемая справка по собственным, а не стандартным процедурам — это уже достоинство хорошего IDE.
Собственно к чему это все. IDE не освобождает от просмотра справочника, она лишь делает этот просмотр чуть удобнее. То есть выдвинутый F0iL тезис "
Есть linux old school программисты, пишущие код в текстовых редакторах из командной строки. Скорость разработки у них не хуже, чем у тех, кто использует IDE.
IDE дает большой выигрыш в уменьшении цикла компиляции, то есть полезно при написании методом тыка или отладке. Но если писать с малым количеством ошибок — выигрыш от IDE не столь велик.
А вот динамически генерируемая справка по собственным, а не стандартным процедурам — это уже достоинство хорошего IDE.
Собственно к чему это все. IDE не освобождает от просмотра справочника, она лишь делает этот просмотр чуть удобнее. То есть выдвинутый F0iL тезис "
придется каждый раз при каких-либо сомнениях или ошибки компиляции производить поиск по справочникам. Вот она и разница в скорости разработки." не верен.Есть linux old school программисты, пишущие код в текстовых редакторах из командной строки. Скорость разработки у них не хуже, чем у тех, кто использует IDE.
IDE дает большой выигрыш в уменьшении цикла компиляции, то есть полезно при написании методом тыка или отладке. Но если писать с малым количеством ошибок — выигрыш от IDE не столь велик.
Есть linux old school программисты, пишущие код в текстовых редакторах из командной строки. Скорость разработки у них не хуже, чем у тех, кто использует IDE.
Вы, видимо, плохо знаете, что могут консольные текстовые редакторы типа vim. Там (при правильном подходе) autocomplete, code indexing и многие другие возможности такие, что многие платные GUI-IDE нерво заикаться начнут.
Нет, vim никогда не заменит хорошую IDE в плане анализа кода и рефакторинга.
Просто языки бывают разные: для JS, PHP и прочих языков с динамической типизацией большой выгоды от IDE действительно нет, и достаточно использования vim или даже Sublime Text.
А вот писать что-то крупное на C++, Java, C# без использования IDE — это уже мазохизм.
Просто языки бывают разные: для JS, PHP и прочих языков с динамической типизацией большой выгоды от IDE действительно нет, и достаточно использования vim или даже Sublime Text.
А вот писать что-то крупное на C++, Java, C# без использования IDE — это уже мазохизм.
Основное в vi — это быстрое программирование рутинных операций. Но прикрутить и вправду можно многое. Так что вот вамещё один путь работы без покупки IDE.
У меня vim, который я только начал обвешивать плагинами, на моей сиплюсплюсной кодовой базе тормозит сильнее, чем clion, а умеет меньше.
Вот в хаскеле ему альтернатив нет, это да.
Вот в хаскеле ему альтернатив нет, это да.
А можно подробней? Это или что-то другое? У меня пока что очень неплохо работает Atom с набором пакетов atom-haskell. Причём, установка довольно прямолинейная, практически без бубна, поддерживается stack.
Охренительная ссылка, спасибо! У меня из всего этого только ghc-mod, neco и nerdtree.
А Atom я пробовал когда он только стал доступен, тогда он был ещё очень сырой, и с тех пор я его как-то не рассматривал. Раз вы им пользуетесь, как оно получается по сравнению с прокачанным vim по ссылке?
Я когда-то пробовал превратить Vim в IDE, но не для Haskell, а для Perl, PHP и JS. Сейчас уже не вспомню, по каким конкретно причинам не зашло. В общем — время загрузки, конфликты с уже установленными плагинами, некоторая непредсказуемость поведения, тогда как по удобству, интуитивности и фичерам всё равно до полноценного IDE не дотягивало. Остался на PhpStorm с плагином CamelCade для Perl. Кроме того, я ценю Vim в первую очередь как мощный и быстро доступный универсальный текстовый редактор, и этой цели после загромождения кучей плагинов он как-то перестал активно содействовать. Вполне возможно, что всё это решаемо, но я не гуру, и тогда не было особого желания копаться в потрохах и тратить время на выяснение.
Для Haskell пока не пробовал. Я абсолютный новичок в Haskell. Года четыре назад пытался изучать этот язык — кажется, пробовал Emacs, плагин для Eclipse, и даже Leksah. Последний IDE оказался (на мой взгляд) слишком нестандартным и сырым. Eclipse работал (когда был в настроении), Emacs, емнип, тоже. Но я быстро попал в Cabal hell, поагонизировал пару вечеров и снёс всё к чертям. :)
Недавно узнал о Stack, и как он решает проблему Cabal hell, так что решил попробовать снова. Гугление быстро привело к Atom. Порог вхождения низкий, функциональности для учёбы вполне хватает. Читаю Real World Haskell, доки по Stack — пока всё работает предсказуемо.
Может, стоит снова попробовать… Если решусь — отпишусь о результатах.
То есть выдвинутый F0iL тезис «придется каждый раз при каких-либо сомнениях или ошибки компиляции производить поиск по справочникам. Вот она и разница в скорости разработки.» не верен.
IDE дает большой выигрыш в уменьшении цикла компиляции, то есть полезно при написании методом тыка или отладке.
Сначала объявили тезис неверным, а потом практически полностью его повторили.
(не говоря уж о том, что дискуссия началась с обсуждения Starter-версий IDE от Embarcadero, у которых нет ни навигации по коду, ни автодополнения, ни «динамически генерируемой справки» про которую вы сами сказали, ни инструментов рефакторинга)
Разницу между тезисами совсем не видите?
Есть такой этап в изучении языка, когда в каждой строчке по ошибке. На этом этапе можно разбираться в предупреждениях компилятора и быстро изучить язык до нормального уровня. А можно — остаться на этом этапе, но облегчить его использованием IDE.
Аналогично с поиском ошибок. Можно разобраться в причинах ошибки и сразу её исправить. А можно при помощи IDE попробовать пару дюжин вариантов — вдруг какой заработает.
То есть IDE очень облегчает работу при слабых знаниях и тем самым — отдаляет изучение языка на лучшем уровне.
А при хорошем владении языком преимущества от быстрой компиляции невелики. В справочники смотреть — все равно надежнее, чем полагаться на память.
Аналогично с кодом — если мы плохо знаем код, то IDE очень полезен. Если весь код в памяти — можно и без IDE.
Так что слишком ранее использование IDE — поощряет плохое изучение языка и исходного кода.
Есть такой этап в изучении языка, когда в каждой строчке по ошибке. На этом этапе можно разбираться в предупреждениях компилятора и быстро изучить язык до нормального уровня. А можно — остаться на этом этапе, но облегчить его использованием IDE.
Аналогично с поиском ошибок. Можно разобраться в причинах ошибки и сразу её исправить. А можно при помощи IDE попробовать пару дюжин вариантов — вдруг какой заработает.
То есть IDE очень облегчает работу при слабых знаниях и тем самым — отдаляет изучение языка на лучшем уровне.
А при хорошем владении языком преимущества от быстрой компиляции невелики. В справочники смотреть — все равно надежнее, чем полагаться на память.
Аналогично с кодом — если мы плохо знаем код, то IDE очень полезен. Если весь код в памяти — можно и без IDE.
Так что слишком ранее использование IDE — поощряет плохое изучение языка и исходного кода.
Какая-то странная у вас дискуссия. Вроде уже давно известно, что использовать IDE — значит существенно сократить время и мозги на рутинных операциях. Если кто-то бездумно тычет в менюшки в IDE, не пытаясь узнать что и как они делают, то это проблема данного конкретного человека, а не IDE. И его не надо пересаживать в блокнот без подсветки синтаксиса, ему просто надо привить правильное мышление.
Вопрос-то не об этом был. А о том, нужен ли IDE, чтобы выучить язык. На мой взгляд, использование IDE на этапе, когда язык выучен еле-еле, препятствует глубокому изучению языка. Вместо выяснения причин ошибки начинаются попытки исправить код методом тыка.
Эффект прилично заметен по школьникам.
Эффект прилично заметен по школьникам.
Я в своей практике видел студентов, которые не умели пользоваться IDE. Привыкли писать код в редакторе с подсветкой синтаксиса, компилировали и запускали вручную, а отлаживали ошибки с помощью отладочного вывода. Когда студент не может исправить ошибку, потому что не владеет инструментом — это печальное зрелище, к сожалению.
Не так уж и сложно научиться владеть IDE. Сложнее наоборот, после удобной работы в IDE перейти в глубокий embeded, где отладочная печать — это максимум, а обычно — лишь светодиодом ножкой чипа подергать.
Ну как реальный пример — баг на этапе инициализации ОЗУ. Или другой реальный пример — баг на старте ядра linux (ещё до момента, когда можно использовать kprintf).
Я вот восхищаюсь коллегой, который эти баги поймал и исправил. Но IDE он не пользуется. Может и не умеет — не знаю. Linux comandline oldschol — это почти религия. Но код у него лучше моего.
Ну как реальный пример — баг на этапе инициализации ОЗУ. Или другой реальный пример — баг на старте ядра linux (ещё до момента, когда можно использовать kprintf).
Я вот восхищаюсь коллегой, который эти баги поймал и исправил. Но IDE он не пользуется. Может и не умеет — не знаю. Linux comandline oldschol — это почти религия. Но код у него лучше моего.
Если исправил методом тыка, а потом разобрался, почему именно так, а не иначе, то что же в этом плохого?.. А если нет — то это, как уже выше говорилось, проблема в мышлении. Если отобрать IDE, будет так же бездумно копипастить из интернета, отбери интернет, будет дёргать коллег… Силой такие вопросы не решаются, человека нужно направить в правильное русло. И если он не захочет туда пойти, то ничего не сделаешь, любознательность и интерес силой не выбить.
Если исправил методом тыка, значит не разобрался, а запомнил. Правильный метод — сначала разобраться, а потом исправлять.
Надо не отбирать IDE и интернет, а вначале учиться по учебнику. И сверять свои ответы с учебником. И только после того, как учебник пройден — запускать IDE. А запуск IDE слишком рано приводит к тому, что учебник оказывается заброшен, язык — недоучен.
Люди во многом рациональны. Если можно не учить язык, надеясь, что IDE все подскажет — значит не будут учить.
Есть хорошая аналогия — в начальной школе запрещают пользоваться калькуляторами. Ибо имея в руках калькулятор — ученик не освоит устный счет.
Не верите — можете на собственном ребенке проверить. :-)
Но иногда не хватает времени и в итоге...
Как пример, помню я, что
Был цейтнот, сразу времени не было, а вспоминать сейчас ту ситуацию — откровенно лень. Да, наверное, и не вспомню уже.
typedef SomeType SomeArra[N_ELEM]; не самая лучшая идея. Ибо описание параметра как SomeArray &pArray иногда приводит к проблемам. К каким, и на каком из десятка используемых компиляторов — не помню. Просто для совместимости лучше так не писать.Был цейтнот, сразу времени не было, а вспоминать сейчас ту ситуацию — откровенно лень. Да, наверное, и не вспомню уже.
Надо не отбирать IDE и интернет, а вначале учиться по учебнику. И сверять свои ответы с учебником. И только после того, как учебник пройден — запускать IDE. А запуск IDE слишком рано приводит к тому, что учебник оказывается заброшен, язык — недоучен.
Люди во многом рациональны. Если можно не учить язык, надеясь, что IDE все подскажет — значит не будут учить.
Есть хорошая аналогия — в начальной школе запрещают пользоваться калькуляторами. Ибо имея в руках калькулятор — ученик не освоит устный счет.
Не верите — можете на собственном ребенке проверить. :-)
Вы хотите сказать, что если дать сходу IDE, то человек не выучит язык. Я считаю что выучит или нет — это зависит от его нужд и осознанности. Уровень компетенции регулирует рынок, если человеку нормально быть недоучкой-формошлёпом, то это его полное право. Если нет, то дальше всё происходит само собой — стало интересно / захотел зп повыше / захотел быть умным — и вот уже человек лезет в дебри языка. В любом случае, это взрослый человек, и он имеет право оставаться на любом уровне компетенции.
О детях (я имею ввиду биологический возраст, а не инфантильных взрослых) я особо рассуждать не возьмусь, эта тема от меня далека, там, наверно, действительно нужно вбивание знаний, чтобы дать базу.
О детях (я имею ввиду биологический возраст, а не инфантильных взрослых) я особо рассуждать не возьмусь, эта тема от меня далека, там, наверно, действительно нужно вбивание знаний, чтобы дать базу.
Исходный тезис: наличие бесплатного IDE далеко не самое важное, что нужно для изучения языка. Хороший учебник намного важнее.
Чтобы исключить мотивацию и способности, есть смысл рассматривать изучение языков одним и тем же человеком.
Дети чуть более рациональны, чем взрослые. Поэтому их можно считать моделью, почти избавленной от внутренней мотивации.
Ну как пример. Мой уровень понимания APL (ни разу в жизни не сталкивался с живым транслятором APL) намного выше уровня понимания JavaScript/HTML, на котором в ходе отладки железки со встроенным веб-сайтом я достаточно много багов убрал.
Собственно по JS я вообще книжек не читал. Зачем? Подправил, проверил в 7 браузерах (IE 8,IE 9, IE 10, старая Opera, FireFox, Safari, Chrome), не вышло — подправил иначе. Чистый метод тыка.
Не было бы быстрого цикла отладки — разбирался бы, учебник бы почитал, а не только справочники. А с быстрым циклом — и так сойдет.
И такое поведение — не единично. Человек рационален и идет к цели ближайшим путем.
Помните «обучение начинающих BASIC должно караться наравне с растлением несовершеннолетних»? BASIC сам по себе — не хуже FORTRAN. Беда в том, что он интерпретатор, то есть имеет короткий цикл отладки. И поощряет написание программ методом тыка вместо изучения языка.
Чтобы исключить мотивацию и способности, есть смысл рассматривать изучение языков одним и тем же человеком.
Дети чуть более рациональны, чем взрослые. Поэтому их можно считать моделью, почти избавленной от внутренней мотивации.
Ну как пример. Мой уровень понимания APL (ни разу в жизни не сталкивался с живым транслятором APL) намного выше уровня понимания JavaScript/HTML, на котором в ходе отладки железки со встроенным веб-сайтом я достаточно много багов убрал.
Собственно по JS я вообще книжек не читал. Зачем? Подправил, проверил в 7 браузерах (IE 8,IE 9, IE 10, старая Opera, FireFox, Safari, Chrome), не вышло — подправил иначе. Чистый метод тыка.
Не было бы быстрого цикла отладки — разбирался бы, учебник бы почитал, а не только справочники. А с быстрым циклом — и так сойдет.
И такое поведение — не единично. Человек рационален и идет к цели ближайшим путем.
Помните «обучение начинающих BASIC должно караться наравне с растлением несовершеннолетних»? BASIC сам по себе — не хуже FORTRAN. Беда в том, что он интерпретатор, то есть имеет короткий цикл отладки. И поощряет написание программ методом тыка вместо изучения языка.
наличие бесплатного IDE далеко не самое важное, что нужно для изучения языка. Хороший учебник намного важнее.Вот с этим полностью соглашусь.
По поводу JS'а — так вам оно и не надо, вы справляетесь и так. Будет надо — начнёте штудировать учебники.
Тут можно конечно сказать, что если все будут так рассуждать и будут посредственными специалистами, то индустрия будет загибаться или развиваться не так быстро, но это философский вопрос… да и мне так не кажется, есть любознательные по природе люди, которых метод тыка не устроит, они захотят разобраться, есть амбициозные. Бывает ещё личностный рост, когда человек сидел-сидел себе, стряпал сайтики на битриксе, а потом подумал «да какого чёрта?!» и начал изучать C# и шаблоны проектирования.
В общем, я думаю что всех знаний не получишь, и стоит понять какое направление приоритетное, и в нём уже рыть всё досконально. Опять-таки, если есть желание :)
Угу, именно так — при наличие IDE можно «справляться и так». Это ограничивает рост квалификации на уровне серенького джуниора. И даже когда надо — я лезу в справочники, а не решаюсь наконец-то прочитать учебник или описание языка. Ибо нужного в данный момент результата так достичь быстрее.
Собственно — зачем учить язык, если все можно найти на stackoverflow? :-)
То есть в принципе понятно, что один раз прочитав хороший учебник, я получу возможность нормально писать на JS. Но… при наличии быстрого цикла для метода тыка — не тянет.
Вот и получается, что языки, на которых я никогда не комплировался, я знаю лучше JS. И это касается не только JS, но и многих языков с быстрым циклом отладки. Например SED.
Что касается приоритетов — любой новый язык дает свои парадигмы. И иногда это очень полезно. Ну как пример — АЛГОЛ-60 дает хорошее понимание, почему не стоит усердствовать с лямбдами. SFC — понимание, как писать process flowи так далее…
Собственно — зачем учить язык, если все можно найти на stackoverflow? :-)
То есть в принципе понятно, что один раз прочитав хороший учебник, я получу возможность нормально писать на JS. Но… при наличии быстрого цикла для метода тыка — не тянет.
Вот и получается, что языки, на которых я никогда не комплировался, я знаю лучше JS. И это касается не только JS, но и многих языков с быстрым циклом отладки. Например SED.
Что касается приоритетов — любой новый язык дает свои парадигмы. И иногда это очень полезно. Ну как пример — АЛГОЛ-60 дает хорошее понимание, почему не стоит усердствовать с лямбдами. SFC — понимание, как писать process flowи так далее…
Собственно — зачем учить язык, если все можно найти на stackoverflow? :-)
Или спросить.
Допиливал я сайтик для своего опенсорс-проекта, не знал, как на CSS что-то сделать, вбросил в один чатик — через полчаса у меня был ответ.
Ну как пример — АЛГОЛ-60 дает хорошее понимание, почему не стоит усердствовать с лямбдами.
… в АЛГОЛе-60.
Как вы, кстати, объясните известную тему с выбором «стоит/сидит/лежит» — ну, когда на столе тарелка стоит, птица сидит, а вилка лежит? В каком учебнике это написано?
Как в анекдоте: умом понять это невозможно, это можно только запомнить. Туда же «Решили послать сходить купить выпить». Слава богу, в языках программирования таких неортогональных вещей почти нет.
Кстати, вот довольно логичное объяснение
никто не пользовался бы word. Потому что «либо плати деньги, либо мучайся со WordPad».
Так обычно либо платят деньги за лицензию/подписку, либо пользуются бесплатными альтернативами (LibreOffice, SoftMaker, и т.д.).
Есть, конечно, еще вариант «скачать с торрента», в некоторых странах (например РФ) он вполне осуществим, а в некоторых странах даже физлицо за такое может словить неиллюзорный штраф.
Ну и вообще, если упарываться на тему «быстро написал и запустил везде», вариант Electron/Cordova может в данном случае даже лучше подойти.
Тут будут не только десктопы (и не только Win и Mac) и мобильные устройства, но еще и тонкие клиенты, или вообще запуск в любом браузере из облака. А с Bootstrap, React/Angular и кучей готовых наработок пилить UI на таком стеке вполне приятно даже без визуальных редакторов, а въехать в тему сможет даже джуниор, благо материалов в наше время более чем достаточно и сообщество, опять же, хорошее.
Тут будут не только десктопы (и не только Win и Mac) и мобильные устройства, но еще и тонкие клиенты, или вообще запуск в любом браузере из облака. А с Bootstrap, React/Angular и кучей готовых наработок пилить UI на таком стеке вполне приятно даже без визуальных редакторов, а въехать в тему сможет даже джуниор, благо материалов в наше время более чем достаточно и сообщество, опять же, хорошее.
А как за пределы песочницы выйти? Обмен по ком-порту, запись файлов данных… Насчет «любого браузера» — это в теории хорошо, на практике — намучались с IE 8/IE 9 даже на простейшем, встроенном в железку сайте.
Но для какого-то класса разработок — да, вполне подойдет.
Но для какого-то класса разработок — да, вполне подойдет.
А в чем проблема добраться до файловой системы, сети, периферии? Если вы запускаетесь в браузере, то это все крутится где-нибудь в node на сервере и там с этим проблем нет, а данные вы получаете уже через какой-нибудь REST API, а если у вас десктопное приложение или под мобильное устройство — то в Electron/Cordova вы не в песочнице, а обладаете почти теми же возможностями что «родное» приложение, и есть или нативные API для этого, или сторонние npm-пакеты и для работы с портами, файлами, коммуникационными протоколами, MQ, СУБД, и т.д.
IE 8 вышел 8 лет назад, не удивительно, что вы с ним намучались :) В современных версиях даже Chromium/FF/Edge с поддержкой стандартов с каждым годом все лучше и лучше.
Выше упоминалась сфера АСУТП, так вот, проект новой SCADA-системы для систем радиотелемеханики, в котором я когда-то был ведущим разработчиком, строили именно с подобным подходом. Ядро на C#/.Net (благо, есть отличная открытая реализация OPC UA клиента и сервера, и всякие вкусности ORM, WebApi и т.д. «из коробки»), а визуализация вся на HTML, CSS, JS, SVG — делается все довольно просто, графические возможности почти безграничны. У заказчиков клиенты были как под Windows/IE у администраторов, так под Linux (FF) на тонких клиентах у диспетчеров, так и на Android-планшетах у технологов и механиков.
IE 8 вышел 8 лет назад, не удивительно, что вы с ним намучались :) В современных версиях даже Chromium/FF/Edge с поддержкой стандартов с каждым годом все лучше и лучше.
Выше упоминалась сфера АСУТП, так вот, проект новой SCADA-системы для систем радиотелемеханики, в котором я когда-то был ведущим разработчиком, строили именно с подобным подходом. Ядро на C#/.Net (благо, есть отличная открытая реализация OPC UA клиента и сервера, и всякие вкусности ORM, WebApi и т.д. «из коробки»), а визуализация вся на HTML, CSS, JS, SVG — делается все довольно просто, графические возможности почти безграничны. У заказчиков клиенты были как под Windows/IE у администраторов, так под Linux (FF) на тонких клиентах у диспетчеров, так и на Android-планшетах у технологов и механиков.
Нам нужно приложение для пусконаладки, работающее с нашим устройством. Причем работающее везде, то есть начиная с windows 95. Никаких серверов, само собой нет — обычный COM-порт или USB-COM.
Ну вот представьте себе погранкатер. Ноут есть у капитана, но он с windows 98 SE и секретными картами. То есть одну нашу программу поставить на него можно, а весь стек C# — уже нельзя. И в руки нам его никто не даст.
Так что C# мимо, браузерные технологии — на уровне IE 5.5, остается Qt и Delphi.
C IE8 была аналогичная история. Радиопередающий комплекс МЧС, права на обновления софта у нас нет. Да и выход в инет запрещен физически. А там на части машин — то ли старая версия IE 8, то ли IE 7. А показывать наш сайт нужно вообще в браузерном окне от чужой программы.
И вот к такому — нужно быть постоянно готовым. И это тоже — АСУТП, просто чуть иной.
Ну вот представьте себе погранкатер. Ноут есть у капитана, но он с windows 98 SE и секретными картами. То есть одну нашу программу поставить на него можно, а весь стек C# — уже нельзя. И в руки нам его никто не даст.
Так что C# мимо, браузерные технологии — на уровне IE 5.5, остается Qt и Delphi.
C IE8 была аналогичная история. Радиопередающий комплекс МЧС, права на обновления софта у нас нет. Да и выход в инет запрещен физически. А там на части машин — то ли старая версия IE 8, то ли IE 7. А показывать наш сайт нужно вообще в браузерном окне от чужой программы.
И вот к такому — нужно быть постоянно готовым. И это тоже — АСУТП, просто чуть иной.
Так сразу и уточняйте, что речь идет про устаревшее оборудование и операционные системы 20-летней давности. Это все-таки довольно специфический случай.
К тому же, я более чем уверен, что написанное на Delphi/C++ Bulder FMX-приложение (мы же начинали разговор с «быстро напиши один раз и запусти везде», то есть это должен быть кросс-платформенный FMX, а не VCL) на Windows 95/98 и соответствующем железе точно так же не запустится вообще.
К тому же, я более чем уверен, что написанное на Delphi/C++ Bulder FMX-приложение (мы же начинали разговор с «быстро напиши один раз и запусти везде», то есть это должен быть кросс-платформенный FMX, а не VCL) на Windows 95/98 и соответствующем железе точно так же не запустится вообще.
Даже более того. VCL-приложения тоже не заработают.
https://www.embarcadero.com/ru/products/delphi/faq
Applications built with Delphi 2009-XE2 and VCL will run on Windows 2000 or later. Applications built with Delphi XE3-XE5 will run on Windows XP and later. Applications built with Delphi XE6-XE7 will run on Windows 7 later.
Читаем внимательней там же
Так что «петлей и веревочной палкой» все можно запустить в win95/98. Чуть-чуть модернизации — и все заработает. Delphi 7 под unicode переделывать сложнее было.
Из-за использования Unicode в качестве строкового типа по умолчанию Windows 95, 98 и ME не будут выполнять приложения, созданные в Delphi 2009 или более поздних версиях продукта. Эти операционные системы не поддерживают строки Unicode, а корпорация Microsoft больше не поддерживает эти версии Windows.Так что «петлей и веревочной палкой» все можно запустить в win95/98. Чуть-чуть модернизации — и все заработает. Delphi 7 под unicode переделывать сложнее было.
Расскажите подробнее. Будете переписывать исходники VСL, добавлять везде врапперы для функций использующих строки?
Попробуете использовать либы от старых версий? У вас очень много свободного времени, видимо. Впрочем, какой бы вариант вы не выбрали, это все будет бесполезно, т.к. VCL само по себе не годно для подхода «быстро написали и потом компилируемся сразу под Win, Mac, Android и iOS», который вы выше заявляли как главное преимущество.
Попробуете использовать либы от старых версий? У вас очень много свободного времени, видимо. Впрочем, какой бы вариант вы не выбрали, это все будет бесполезно, т.к. VCL само по себе не годно для подхода «быстро написали и потом компилируемся сразу под Win, Mac, Android и iOS», который вы выше заявляли как главное преимущество.
Видите в чем дело… я работал с библиотекой. реализующей обратную функцию (unicode в неюникодном VCL) и понимаю, что мест, где придется менять код — совсем немного.
Ещё проще — сохранить совместимость исходного кода со старыми версиями без unicode.
А с FMT — посмотрим как пойдет переход с VCL на FMT. Пока что приложение у нас на VCL (на CDBuilder 5). Вариантов довольно много, например — разработка на VCL и автоконвертер на FMT.
У нас в этом приложении — пяток человеко-лет труда. Дешевле потратить пару месяцев на перенос, чем писать параллельную версию.
Ещё проще — сохранить совместимость исходного кода со старыми версиями без unicode.
А с FMT — посмотрим как пойдет переход с VCL на FMT. Пока что приложение у нас на VCL (на CDBuilder 5). Вариантов довольно много, например — разработка на VCL и автоконвертер на FMT.
У вас очень много свободного времени, видимо.
У нас в этом приложении — пяток человеко-лет труда. Дешевле потратить пару месяцев на перенос, чем писать параллельную версию.
Sarcasm on
Специфический? Скажите, а ваш домашний роутер для настройки windows 10 с последними апдейтами требует? Или настраивается с чего угодно, начиная с windows 3.10?
Sarcasm off
Это довольно типовой случай, просто чуть другой вид АСУТП.
У FMX основное требование — DirectX 9.0, а он есть под Win98SE. Так что выпадает только Win95.
Специфический? Скажите, а ваш домашний роутер для настройки windows 10 с последними апдейтами требует? Или настраивается с чего угодно, начиная с windows 3.10?
Sarcasm off
Это довольно типовой случай, просто чуть другой вид АСУТП.
кросс-платформенный FMX, а не VCL) на Windows 95/98 и соответствующем железе точно так же не запустится вообще.
У FMX основное требование — DirectX 9.0, а он есть под Win98SE. Так что выпадает только Win95.
Мой домашний роутер вообще через telnet/ssh консоль конфигурируется. Для любителей GUI и удобной настройки есть ПО, для которого нужна ось не старше Win 2000 (в старых версиях, в новых возможно уже и XP).
Впрочем, и более попсовые роутеры, веб-админка у которых не работает в IE 7 мне тоже попадались.
Впрочем, и более попсовые роутеры, веб-админка у которых не работает в IE 7 мне тоже попадались.
Ну а мне — наоборот, попадались "роутеры", чья веб-настройка не работает в более-менее современных браузерах.
Вы сами не читаете ссылки, которые приводите. Там прямым текстом написано, что минимальная версия ОС, на которой могут работать FMX-приложения — это Windows XP SP2 или Server 2003.
Не говоря уж о том, что с учётом прожорливости FireMonkey, железо, времён Win98 что-то чуть более сложное чем хеллоуорлд нормально просто не потянет.
Не говоря уж о том, что с учётом прожорливости FireMonkey, железо, времён Win98 что-то чуть более сложное чем хеллоуорлд нормально просто не потянет.
Железо времен Win98 и пользователь, работающий на win98 — это разные вещи. Если бы железа не хватало для ворда и офисных игрушек — его бы сменили. Так что железо будет всего лишь 10-15 летней давности.
А минимальная версия… Вы хоть раз писали в описании библиотеки минимальную версию? Её пишут с большим запасом, с учетом работы всех функций. А в конкретном приложении все функции библиотеки не нужны, так что реально — можно и меньше.
А минимальная версия… Вы хоть раз писали в описании библиотеки минимальную версию? Её пишут с большим запасом, с учетом работы всех функций. А в конкретном приложении все функции библиотеки не нужны, так что реально — можно и меньше.
Это довольно типовой случай, просто чуть другой вид АСУТП.
Тут просто нужно иметь в виду, что сама сфера АСУТП — это всего лишь небольшой залив в огромном океане мира разработки ПО, а проекты, с которыми вы знакомы — лишь капли в нем.
Мне тоже несколько лет назад пришлось столкнуться с необходимостью делать большой проект под плату с процессором Am186 используя Borland C Compiler 3.1 выпуска 1992 года, но я прекрасно понимаю, что 99% программистам в современном мире с этим столкнуться не придется, и у меня хватает ума не навязывать необходимость подобного опыта и использования этих средств другим :)
Тогда не забудьте, что само программирование — лишь капля в море иных профессий. Хотите массовую профессию — учитесь торговать в ларьке.
Это идеологический выбор — специализироваться в чем-то одном или уметь все, но понемногу.
ICP DAS I-7188? Хорошая машинка.
Это идеологический выбор — специализироваться в чем-то одном или уметь все, но понемногу.
плату с процессором Am186
ICP DAS I-7188? Хорошая машинка.
ICP DAS I-7188? Хорошая машинка.
Он самый, плюс его старшие братья из 8000-серии.
99% программистам в современном мире с этим столкнуться не придется
Ну вы сами видите, что вероятность нарваться на того, кто работал — несколько больше одного процента.
У меня на него был свой собственный язычок написан. Байт-код с интерпретацией и на нем и на 386. Служил в качестве клея между ФБ на паскале.
А вот вам хороший пример изучения технологии без живого железа. Ни котлоагрегаты, ни евротермы к нам в Питер не возили.
И где, кроме embedded devices, этот Си?Си много где. До сих пор — один из самых популярных языков для разработки. Полагаю, что никуда он не денется — по крайней мере, до тех пор, пока будем программировать компьютеры Тьюринга.
мне не дадут работу, потому что я не знаю технологий, а технологии я не узнаю, пока не получу работу
Вы же не думаете, что сеньоры и миддлы от рождения молотят по клавиатуре? Никто в здравом уме не подпустит новичка к серьезному проекту.
0 -> джуниор -> миддл ->… В таком порядке. Джун умеет решать задачи на своем уровне в отличии от «нулевика».
Кто хочет — ищет возможности. Кто не хочет — ищет причины (с). Адресовано не лично вам, а сферическому читателю :)
Есть такая проблема, знания быстро устаревают. Можно попробовать выбрать язык и технологию, которая устаревает медленно. Как пример приведу Golang: однажды приобретенные знания остаются актуальными годами.
Я много раз ловил себя на мыслях, что всякие новомодные каналы, горутины, зеленые нити корнями уходят в 70ые годы. Даже модные блокчейны на этой же базе строятся. Получается, что её достаточно, чтобы не сходить с гребня волны
Согласен. Мне довелось быть знакомым с oberon, ada и после них многие новые фишки в языках видятся, как более или менее удачное применение старых идей.
Полностью согласен. Где-то пол года назад сильно думал чего бы нового изучить, при этом всегда был страх что я потрачу много времени на изучение и когда я хоть что-то смогу с изученной технологией сделать она уже устареет. В итоге начал учить ассемблер и основные принципы работы микропроцессоров. Эта тема врядли скоро устареет, а знания эти помогут лучше понять тотже С/С++. К тому-же открываются большие перспективы для дальнейшего обучения.
Хм… раз мне кажется довольно логичным, что "5" + - "2" равно "5-2" то джаваскрипт мозга у меня запущенный.
черт, это потрясающая иллюстрация к вопросу «зачем нужно учить типы данных».
если всё так, то такая конверсия, на мой взгляд, усложняет а не упрощает жизнь.
если всё так, то такая конверсия, на мой взгляд, усложняет а не упрощает жизнь.
какая оскорбительная картинка
в англоязычном сообществе вас бы уже предали анафеме, а не плюсы ставили
в англоязычном сообществе вас бы уже предали анафеме, а не плюсы ставили
да норм картинка, правда старенькая.
Там еще много всего интересного можно найти;
Не давно на собесе было.
console.log(1);
setTimeout(function () {
console.log(2);
}, 0);
console.log(3);
Там еще много всего интересного можно найти;
Не давно на собесе было.
console.log(1);
setTimeout(function () {
console.log(2);
}, 0);
console.log(3);
Всегда можно умножать оба слагаемых на единичку. Костыль, зато нет таких сюрпризов как на пикче сверху.
На самом деле бред, в моем случае помог и по прежнему помогает letcode, topcoder, kaggle и др. Ровно как и петпроджекты, не раз слышал истории о том, как люди имея всего 1 персональный проект после вуза успешно приходили на senior позиции в Я не имея до этого никакого опыта. Вывод -было бы желание. Хотя по своему опыту -соло учиться сложно, держать уровень мотивации и выбирать направление лучше с ментором. Обычно имея хорошего наставника вам понадобится значительно меньше времени. Но нет ничего не достижимого- алгоритмизация вычислений это то, чему можно научить любого, да потолок у всех разный, но это уже совсем другая тема.
Потратить это же время на дальнейшее обучение будет более выгодным.это рекурсия/бесконечный цикл:
сейчас поучиться, чтобы потом больше зарабатывать
сейчас вложить, чтобы потом больше получить
Не бесконечный. Есть и верхняя планка (пусть бы и миллиард в год, но есть) и падающая отдача. И учиться после какого момента эффективнее на рабочих задачах.
на регулярной работе часто бывает так, что учишься и зарабатываешь одновременно. Это самый удачный вариант :)
Вы привели два крайних случаях.
На деле же надо половину времени учиться, половину — работать.
Судя по своему опыту, это хорошо окупается.
На деле же надо половину времени учиться, половину — работать.
Судя по своему опыту, это хорошо окупается.
Сейчас я смотрю на это и думаю – а стоит ли вообще за такие деньги шевелиться. Потратить это же время на дальнейшее обучение будет более выгодным. С другой стороны, даже небольшой выполненный заказ – это +1 довольный клиент. Но я придумал, как разрешить эту дилемму.
и тут по идее должна быть решения дилеммы но я ее так и не заметил, может невнимательно прочел конечно..)
И действительно. Уважаемый kbaa, расскажите, пожалуйста, детальнее про выбранный подход к насущной проблеме, а то недосказанность некая получается.
Хотел написать поизящней, но, видимо, перемудрил и не совсем удачно сформулировал мысль. Смысл, что в ситуации, когда есть очень дешевые заказы и стоит выбор — тратить время на них, или на обучение, я решил попробовать международные биржи фриланса. Там выяснилось, что даже простые задачи могут стоить уже более адекватных денег. Плюс еще английский подтянуть. Я посчитал это достойным компромиссом, рассказ про это будет во 2й части
>> Вспомнил, что когда-то хотел стать программистом. Мне было это интересно. А сейчас мне 30
Привет. В 41 год, в 2015 я решил стать программистом. Через год, когда мне исполнилось 42, стал. Я не был лучшим, я был джуном в оутсорсной компании, но я был и стал. Возраст — не смерть.
До 42 лет у вас еще есть время для выбора и изучения технологии и фреймворка ))
Привет. В 41 год, в 2015 я решил стать программистом. Через год, когда мне исполнилось 42, стал. Я не был лучшим, я был джуном в оутсорсной компании, но я был и стал. Возраст — не смерть.
До 42 лет у вас еще есть время для выбора и изучения технологии и фреймворка ))
Глаза боятся — руки делают. Когда я осознал, что не обязательно сперва становиться суперпрофессионалом, чтобы уже начать что-то делать — стало намного проще жить. Когда что-то начинаешь — на практике будет легче понять свои слабые и сильные стороны и корректировать прогресс в нужную сторону.
Думаю, ваша история тоже может пойти многим на пользу. Больше примеров из жизни — больше вероятность, что кто-то прочитает и воодушевится.
Думаю, ваша история тоже может пойти многим на пользу. Больше примеров из жизни — больше вероятность, что кто-то прочитает и воодушевится.
на самом деле надо знать предмет если не досконально, то очень хорошо, прежде чем подписываться на серьезную работу за деньги, иначе это называется простым словом «мошенничество»
мода на идею доморощенного программиста вводит в заблуждение о простоте профессии и ведет к производству ни на что не годных «специалистов», которые ждут больших денег, прочитав учебник
мода на идею доморощенного программиста вводит в заблуждение о простоте профессии и ведет к производству ни на что не годных «специалистов», которые ждут больших денег, прочитав учебник
на самом деле надо знать предмет если не досконально, то очень хорошо, прежде чем подписываться на серьезную работу за деньги, иначе это называется простым словом «мошенничество»Т.е. визитку на Битриксе для автомастерской должен писать непременно сеньор с 10 годами опыта работы в Гугле и тремя высшими?
Мошенничество — это когда результат не соответствует требованиям заказчика. Если с требованиями можно справиться, пройдя десяток уроков в интернете, то всё честно.
мода на идею доморощенного программиста вводит в заблуждение о простоте профессии и ведет к производству ни на что не годных «специалистов», которые ждут больших денег, прочитав учебника это уже проблема адекватной оценки себя.
Внезапное желание стать разработчиком. Личный опыт