Comments 155
По теме — автор абсолютно прав. Огромное количество людей сейчас учат технологии, а не алгоритмы и языки. Такой «тренд» во всех сферах.
Вы будете удивлены, но новые серии Масяни продолжают выходить до сих пор. От того же автора. http://www.mult.ru. Последняя серия вышла 1 июня 2016 г.
Мне казалось Масяню перестали рисовать году 2006… Хотя уже и не вспомню сейчас всех подробностей.
Prototype (кто-нибудь помнит этот фреймворк?).
Шёл из коробки с symfony В поддерживаемом проекте году этак в 2012 заменён на jQuery.
Dojo (кто это помнит?!)
Не далее как в начале этого года предлагали переписать проект на Symfony 2.3 c Dojo на фронте на Symfony 3 + React
Хотелось бы узнать смысл, что вы хотели узнать этим тестом?
И что, по вашему мнению, показывает присутствие/отсутствие этого навыка?
Может мидлы которые работают с одним языком и обладают подобным качеством.
Но очень сомневаюсь, что сеньеры плотно знакомые с 5-10 языками и 3-4 платформами, по 2-5 лет практики на каждом, смогут писать код ручкой.
Кто помнит как в winapi получить scan code и преобразовать в wchar текущей кодировки? Например на delphi.
Или что именно настраивать в адроид Intent, что бы передать URL в другую APK.
Задача Delphi на форме отловить wm_keydown, и при нажатии клавиши вывести символы которые соответствуют этой клавише для всех используемых языков системы.
А так же утверждаете, что темплейт этого ответа можно использовать для подобных вопросов «И такой ответ, прикиньте, удовлетворит любого интервьюера.»
Как-то слабо коррелирует с
«Мой личный опыт показывает, что люди, претендующие на позицию мидла и выше заслуженно, пишут код на бумажке с легкостью. Все без исключения.»
На любой платформе, любом IDE.
Копирование в буфер клавиатуры текста в HTML формате, где каждое 2е слово italic.
Ну и если позволят знания, то с добавлением имиджа в середину текста.
Если сложно, то загрузка указанного ХМЛа, подсчет количества русских букв «я» в этом хтмле.
ps
спорим, что код никто так и не увидит.
я буду это писать на C, а никак не на C++. По той же простой причине, по которой я не ем на завтрак картон: я не дебил.
А можно поподробнее расшифровать вашу мысль? Чем вам не угодил (вообще или в данной ситуации) C++?
«И какие это языки? Надеюсь С++ там есть?»
>я буду это писать на C, а никак не на C++
Без проблем С тоже подойдет. Упростим задачу, HTML файл локальный.
А вот является ли способность написать код на бумажке подтверждением чего либо, кроме тщательной подготовки к собеседованию — это уже другой вопрос.
Не бросайтесь в крайности. На собеседовании никто не просит написать код с использованием апи. Если бы меня попросили написать на бумажке такую задачу, то на питоне я бы написал что-нибудь в стиле:
buffer = ' '.join('<i>{0}</i>'.format(w) if i%2 else w for i, w in enumerate(get_current_selection().split())) А как положить переменную buffer в буфер и как реализовать get_current_selection я бы погуглил.
Замечу не написанием блоксхемы, или описание принципа решения, а именно КОД.
Что дает подобный тест?
Я ходил недавно на собеседование и как раз писал код на бумажке. Никаких проблем забываниями сигнатур API функций у интервьюверов не было. Достаточно примерно помнить что функция есть в стандартной библиотеке. А вот практические навыки твои видно просто прекрасно.
Например:
Решаем простую алгоритмическую задачку на java, которая свелась к fold (свертке списка). Ну я пишу 2 решения — одно циклами, другое на Stream API. Меня спрашивают — а как бы нам это сделать параллельно. Я отвечаю — можем использовать AsParallel в Stream API, но в общем это может быть медленнее(из-за кривизны Stream API), так что обязательно надо бенчмаркать. Просто смотря на код — фиг поймешь быстрее будет или медленнее.
Интервьювер сразу видит что я и код написать могу 2х стилях (функциональный и императивный) и то что неплохо знаю стандартную библиотеку java и границы применения ее API
Ну и если вы дете в команду интервьювера -ему же интересно как вы там КОД писать будете. Как переменные назвать (a, b, c или что-то более осмысленное), как методы. Насколько легко ему будет понять — что вы пишете.
Так что — имхо писать код на бумаге во время собеседования — одна из самых логичных практик.
Ну вы поняли. Может это и не про вас, но я таких людей встречал. Какой смысл отказываться от ИДЕ?
Какой смысл отказываться от ИДЕ?
Ну ты сейчас ящик Пандоры открыл.
Если совсем примитивно, пользователю линукс нравится полагать, что он хозяин положения и крепко держит в руках поводья. При этом для него достаточно имитации. То есть поводья которые он держит заходят в черный ящик, а оттуда появляются с другой стороны и ведут к лошадям. Когда пользователь дергает за них, то позади ящика они вроде как в точности реагируют на его действия.
Лошади правда могут повести себя совсем не так как ожидалось, но сами поводья работают исправно. Настолько исправно, что человек не замечает черного ящика и думает, что его руки погружены по локоть в каждую лошадь. И с места кучера все очень хорошо видно, хоть и все лицо в пыли, а красные глаза слезятся от ветра.
Пользователь Виндовза для него выглядит как жирный недалекий турист, который сидит в мягком комфортном салоне кареты позади и все команды подает не лошадям, а специально нанятому профессиональному кучеру, по рации. Вместо того, что интересоваться повадками и анатомией несущих его животных он занимается своими делами, спит, читает книги и смотрит в окно на красивые пейзажи. Вот лох. Как так можно, ехать на дилижансе и ничего не знать про лошадей?
В реальном мире (без метафор) это выглядит как следующий пример:
Допустим пользователю Винды и Линукса вдруг стало нужно поменять скринсейвер и задержку его появления.
Первый мышкой через набор менюшек, выберет нужный скринсейвер и потянет ползунок на нужную задержку.
Второй вызовет терминал и там напишет что-то наподобие sudo set screensaver «aqua» set delay 100000 ms (псевдо команды).
В реальности и первый и второй пользователь обратились в черный ящик через предоставленный им интерфейс и совершили абсолютно идентичные действия с идентичными последствиями.
Но у пользователя линукса возникает иллюзия, что он это сделал каким-то более прямым правильным способом. Что использовал немного магии, заюзал шорткат. Как бы залез под капот и что-то там подкрутил почти неглядя под восторженные вздохи воображаемой публики.
Короче говоря, таким людям просто нравится набирать текст в консоли. Все.
Хотя золотая середина имхо это IDE с шорткатами.
Fixed
Юникс-системы это и MacOS, между прочим. Более того — это самая распространенная пользовательская Unix-система. Да и без неё всякие Ubuntu всё больше используют обычные пользователи, не имеющих вообще представления о консоли ни в никсах, ни в винде. Вот у нас на несколько сотен пользователей никсов приходится несколько десятков пользователей винды (из-за специфического софта, необходимость установки винды нужно обосновывать руководству и технарям), при этом активно работают в консолях обеих систем хорошо если два десятка человек, при том, что это даже не все разработчики.
Из десяти предложенных, потому что кнопку «выбрать свой» в этой версии отключили — слишком сложно, смущает пользователей.
> потянет ползунок на нужную задержку
Из трёх стандартных.
Просто это очень похоже на детское «я тебя убил — у меня супер-оружие… — ненене, а у меня суперброня, так что не убил. Убил — не убил. Убил — не убил...»
Вообще, слегка развивая аналогию, можно сказать, что сторонники Linux намеренно себя ограничивают (зачем я будут использовать IDE, которая может найти все включения произвольного символа, отрефакторить код и т.д., я лучше буду использовать редактор, который ничего этого не умеет, будут помнить, что где находится, и хотя я не смогу объяснить, зачем я это помню, у меня будет возможность при случае этим козырнуть), а потом этими ограничениями гордятся и впадают в праведный гнев, когда кто-то не признает их превосходства над собой.
Впрочем, этим не только линуксоиды грешат, но и не-ИТ-шники тоже.
Всё-таки не согласен. Да, многие пользователи gnu/linux именно такие, как вы описали. Но между gnu/linux и windows есть отличие, имеющее мало отношения к gui vs console. Для gnu/linux доступна куча информации о внутреннем устройстве ос и всех её компонентов. И доступны все исходные коды. В случае возникновения проблемы можно зайти в её изучении настолько глубоко, насколько вы захотите. Вплоть до самостоятельного нахождения бага и исправления memset (a, b, c) на memset (b, a, c) (условно) в коде какой-нибудь утилиты.
Недавно у меня перестал грузиться мой дебиан. Я достал бекап ос, сделал diff между "хорошей" забекапленной версией и "плохой" текущей, долго перекидывал туда-сюда файлы, пакеты. Наконец, докапался до проблемы. Выяснилось, что почему-то исчез один каталог. Я его создал в "плохой" системе и она начала грузиться.
Вы скажете, что всё то же самое можно сделать и в винде, пускай привлекая консоль. Допустим, но что если пойти ещё дальше? Допустим, я сделал diff на две эти системы debian, увидел, что ядро одно. Значит, ядро можно исключить из рассмотрения. Значит, дальше ребутаться между системами больше не нужно (это время отнимает), можно просто переключаться между ними с помощью systemctl switch-root или ещё чего-то в этом духе, не перезагружая ядро. Переключаться туда-обратно, таскать туда-сюда файлы, выяснять, в чём причина проблемы. Даже если бы опции switch-root не существовало бы, её можно было бы запросто написать.
Винда может так? Сомневаюсь.
В процессе такого же копания с виндой запросто можно упереться туда, где документации уже нет, а код закрыт.
Вот недавно ставил windows 7. Обновлял. В какой-то момент перестал обновляться. Обновление виснет. Вот как эту проблемы решить? В дебиане есть apt-get, он устроен относительно просто. apt-get update по сути просто скачивает несколько файлов, причём он пишет в консоль, какие именно. Можно прикинуть, в чём там может быть дело, 404 file not found или ещё чего. На крайняк открыть сорцы. В случае с windows непонятно, куда копать дальше. Пришлось поискать в инете. Оказалось, нужно вручную скачать определённые обновления и установить. Как я должен был сам до этого допереть?
Как тут не вспомнить недавнюю историю "Билл Гейтс не смог установить Windows 8.1". И вроде у него такая же проблема была, винда в какой-то момент перестала обновляться. :)
Ну значит я вас не понял :)
Просто интересует, почему ваши синьоры выбирают путь отшельников, вместо того, чтобы пользоваться вещами, ускоряющим написание кода, навигацию, поиск и рефакторинг?
Вам они ускоряют, а сеньорам — нет. Все просто.
Действительно! Спасибо что поделились своей незыблимой истиной!
Пойду выбью это на скале.
Рассчитывать на диалог не вижу смысла.
Мне кажется между нами возникло недопонимание.
Что вы вкладываете в понятие тестовый редактор?
Правильно ли я понимаю, что ваши сеньоры не пользуются ни подсветкой синтаксиса, ни автодополнением кода, ни навигацией (например ctrl+click из IDEA)?
Т.е. и vim и emacs с подобными возможностями мы не рассматриваем как текстовый редактор, потому что там это тоже все можно накрутить при определенном желании.
Мне действительно интересно, как можно программировать эффективно, не имея под рукой документацию и возможности автоматизации.
Про недостатки переиспользование способа «сейчас начну писать, а там как пойдет» я не спорю. Я не понимаю отказа от автоматизации рутинных задач.
Я бы не прочь и статью прочитать с описанием вашей методики и наблюдений
Несомненно, отсутствие базовых знаний (в том числе и разрабатываемого проекта) тормозит разработку. Это как если писать на новом фреймворке — каждый раз будешь гуглить «а как сделать X в фреймворке Y».
Но, по моим ощущениям, ваш подход возможен в условиях разработки и поддержки очень небольшого кол-ва проектов. Либо вы занимаетесь только одним проектом в течение длительного времени и не выпадаете из его «контекста».
Но я не представляю, как можно рефакторить и дорабатывать проекты, которые ты, например, делал год назад.
Как у вас происходит изучение новой библиотеки/фреймворка?
Можно узнать у вас, в какой области вы ведете разработку?
Как выглядят задачи, которые вы решаете?
Я ответил на ваш вопрос?
Несомненно. Спасибо за подробное объяснение. Прошу прощения, если диалог со мной понизил вам карму.
Возник еще вопрос в продолжение темы.
Мне было бы интересно узнать, чем вы пользуетесь при обдумывании архитектуры?
UML, псевдокод, какой-то софт, ручка+листочек, просто размышления в голове?
В онлайн курсе Барбары Оуклей «Научись учиться» (https://www.coursera.org/learn/learning-how-to-learn) как раз было интервью с математиком, который говорил о таком же подходе. Он часто пытается решить задачу, но если не получается, он отправляется ездить на велосипеде, или на скалодром — переключиться с задачи. И часто именно в такие моменты ему приходит решение.
Про modelling language интересно было бы услышать. Но, я мало знаком с этой темой, поэтому, только если у вас свободное время и желание: не могли бы вы раскрыть немного эту тему? Что пытались сделать и с чем столкнулись? Правильно ли я понял, что UML не позволяет отобразить все, что необходимо при проектировании архитектуры?
Как оно может отучить смотреть в код, если документация зачастую неполная или не отражает контракт полностью? А вот быстрая навигация в код, который вызываешь — всегда под рукой. Причём на любую глубину. В том числе с учётом IoC. Да и автоматически всплывающих подсказок у меня, например (с дефолтными для них настройками), самый минимум — ЧЯДНТ?
PS ваши комментарии ну очень похожи на не осилил — значит потенциально вредно… надеюсь, что так только кажется.
не знаю уж, почему все считают своим долгом обратить меня обратно в свою веру
подсказка: из-за категоричности ваших суждений. Они вызывают условный butt hurt на уровне восприятия.
Не можете без IDE — отлично, значит IntelliJ не разорятся, а им я желаю только добра.
Они JetBrains
PS продукты MS называть IDE у меня не всегда язык поворачивается… Перегруженные, неудобные, с кучей проблем при переходе от версии к версии… По крайней мере так мне это запомнилось ещё по университету.
— навыки алгоритмизации и декомпозиции задач
— самые начальные знания управляющих конструкций
— знание стандартной библиотеки на уровне «есть функция/метод которые делают вот это»
Если брать не абстрактные холивары, а конкретную работу, то там всегда есть какой-то стек, к которому нужно подготовится. Если разработчик настолько ригидный, что вечно застревает в каком-то стеке (далеко не классическом), инфантильно ненавидит Angular2, Ember, React, etc словно это готовые коммерческие проекты, в которых кто-то кому-то должен, то это уже о чем-то говорит? Никто же не просит контрибьютить ежедневно, но поддерживать актуальное состояние знаний технологий нужно, а главное иметь фундаментальные знания, позволяющие включится в поток после перерыва без нытья.
А нытье будет, просто потому что страшно, что, освоив один инструмент нельзя делать одно и тоже всю жизнь — но это же никак не отличается от остальных профессий. Если хочется больше стабильности, надо подниматься на уровень выше.
Dojo (кто это помнит?!)
Я помню, он в ZF1 шёл довеском.
Да сколько можно-то! Когда уже у вас, мерзких хипстеров, делящих фреймфорки на "старое дерьмо" и "новомодное дерьмо" выйдет из моды ныть на новые инструменты.
Фронтенд очень быстро развивается и это хорошо, новые инструменты в среднем лучше и адекватнее старых. Всяко лучше чем 4 года ждать патч от Oracle.
React + Redux + Babel + JSX + ES6 + Browserify + PostCSS + Webpack
Вот тут автор жестко палится тем что нету у них такого проекта, а он просто накидал слова из гугла. Browserify + Webpack, масло масляное.
"Главный бармалей" в веб-студии который не может написать простенький сайтик с бекендом, как это обыденно.
Оберткой над чем являются React, Webpack?
Python — это обертка над C.
Java — это обертка над C++.
C++ — это обертка над C.
C — это обертка над ассемблером.
Ассемблер — это обертка над машинными кодами.
Вывод:
Давайте сразу на машинных кодах писать.
С каких это пор C++ стал оберткой на C? C++ написан на C++ и не является надмножеством C, так что максимум: C++ — это обертка над ассемблером.
JavaScript-движки — либо VM, либо JIT-компиляторы, лиюо что-то посередине.
По сути, то же что и Java-движки. Скажем, апплеты тоже компилируете вы, а запускаются они на стороне пользователя.
P. S. Про WebAssembly: ничего против не имею, джавистам, плюсистам и питонистам станет проще.
Но я не знаю, сколько времени осталось, пока они не вошли в категорию «X — дерьмо!».
Учите
Вообще, посмотрите, например на ремонт электроники. С паяльником сидят только энтузиасты. В сервисных службах же, тупо меняют блоки, даже не могут сказать как этот блок в деталях работает. Все усложняется. Да и не хотят разбираться, ибо компания снижает себестоимость.
Программирование такая же область, где энтузиасты изучают алгоритмы и паттерны и пишут фреймворки, а те кто хочет рубануть денег «в легкую» — интегрируют JQuery плагины. Печалька.
var a = {"a": 0}; a.b, то ошибку поймаем только в рантайме. Никакого этапа компиляции тут нет. Да и вообще, это, типа, не ошибка. a.b — это не синтаксическая ошибка, это просто undefined. Да и вообще, огромное количество кода, который в компилируемых языках был бы запрещён, в Javascript разрешён. Это не ошибка, это undefined. Список можно продолжать, ищите сами списки в интернете вида «100 недостатков Javascript». Это просто кошмар для человека, привыкшего к компилируемым языкам, таким как C, C++, Haskell, а также к такому красивому, пускай и заброшенному и малофункциональному языку на сегодня как Pascal.Сейчас хайп вокруг разных технологий на базе js, но неудивлюсь, если вдруг очень скоро будет признано, что js — гэ, а вместе с ним node и все фреймворки на нём :)
И, кстати, многие функции стандартной библиотеки C возвращают в качестве признака ошибки 0 или -1. Это не считая kernel panic/BSOD.
А я не говорил, что единственная проблема javascript в том, что он некомпилируемый. Если взять javascript и, так сказать, в лоб его переделать из интерпретируемого в компилируемый (возможно, добавив попутно типизацию), он всё равно сохранит многие недостатки.
Да и вообще, проблема не в том, что javascript некомпилируемый. Просто я перечислил известные мне компилируемые языки как положительные примеры, как примеры "хороших" языков в отличие от "плохого" javascript. Python тоже, наверное, можно было привести в качестве примера "хорошего", но я не знаю python, поэтому упоминать его не стал.
с сильной/слабой типизацией
У javascript проблемы не только с типизацией. Слышал, что есть некий typescript. Думаю, эти ребята просто взяли javascript и в тупую добавили типизацию, не изменив всего остального. Значит, многие проблемы javascript всё равно остаются.
И, кстати, многие функции стандартной библиотеки C возвращают в качестве признака ошибки 0 или -1
Да, это плохо. Но если говорить про C++, это решаемо. Можно обернуть эти функции в обёртки, которые возвращают std::optional, std::variant и т. д.
Это не считая kernel panic/BSOD.
Как пример хорошего языка приведу Haskell. Наверное, привёл бы тут ещё и Python, если бы знал его. (Сюда же, видимо, Go и Rust.) Haskell с одной стороны не подвержен всевозможным утечкам памяти, сегфолтам и т. д., в отличие от C/C++, но с другой стороны нет вот этого вот бардака в стиле "любая переменная может оказаться null, а ещё undefined", как в javascript
Вполне возможно, что на js вообще программировать перестанут, а будут писать лишь на том же typescript или на чём-то ещё и потом транслировать в js. Ну или браузеры введут новый язык. И программирование на js исчезнет как со стороны клиента, так и сервера. Вместе со всякими node. Я это просто к тому, что сам вот этот js в какой-то момент может быть объявлен отстоем
2) Недостатки JS могут удаляться потихоньку, объявлением части функциональности deprecated с последующим выпиливанием.
Даёшь сайт http://jssadness.com (по аналогии с http://phpsadness.com )
Правда в том, что большей части разработчиков фиолетово на сам проект. Куда важнее чувствовать себя «в тренде». Не быть лохом.
Таки да.
Но так поступают как раз лохи. :)
И мало кто из работодателей сознается, что набирает людей для поддержки унылого проекта на фреймворках полугодовой давности.
Таки да. В вакансиях тех работ, где я работал, было куча умных словечек, которые не использовались в проектах. :)
Сингулярность ближе, чем ты думаешь.
Да? :)
Сингулярность — это Windows XP + Opera 12. :^)
Быть настоящим и писать код VS перебирать и казаться