Комментарии 22
НЛО прилетело и опубликовало эту надпись здесь
Как минимум раз в год надо чистить, согласен
Табличную вёрстку учить несложно, а вот тестировать письма — это тот ещё гемор. Но сейчас есть фреймфорки типа такого mjml.io конечно, он берёт на себя эти знания древних технологий.
Табличную вёрстку учить несложно, а вот тестировать письма — это тот ещё гемор. Но сейчас есть фреймфорки типа такого mjml.io конечно, он берёт на себя эти знания древних технологий.
А, это про Google Doc? Там технологии 2011 года. Старые, да.
Там в опроснике в паттернах опечатка — composit вместо composite и 3 (три) паттерна под названием mixin.
Тема, конечно, любимая холиварная. Но не могли бы вы описать, в чём суть _методологий_ Waterfall и Agile? Кажется мне, что и остальная часть этого опросника — набор случайных слов из разных предметных областей.
Один из важных советом по прохождению интервью: никогда не верить перечисленным в вакансиях спискам требований и технологий. Всегда на месте выяснять что же на самом деле нужно работодателю.
Один из важных советом по прохождению интервью: никогда не верить перечисленным в вакансиях спискам требований и технологий. Всегда на месте выяснять что же на самом деле нужно работодателю.
В свое время видел такую шкалу:
Оцените ваши знания инструмента:
1. Не слышал.
2. Слышал.
3. Видел, как используют.
4. Пробовал.
5. Регулярно использую.
6. Обучаю пользоваться.
7. Читал исходники
8. Реквестил патч-фикс
9. Мейнтейню репозиторий.
10. Я — автор.
Есть ситуации, к применению С++, даже 10 по этой шкале, означает 70% знания. Бьёрна Страуструп.
Интересная шкала, но не очень линейная. середину нужно чуть более дробную.
По своему опыту могу сказать — 7 и 6 (и даже 8 и 5) могут идти и в обратном порядке: например, заслал фикс для какого-нибудь маленького модуля в большом фреймворке, который применил в одном проекте и больше не трогал. Хотя это, конечно, скорее исключение, чем правило.
В шаблонах проектирование mixin встречается 3 раза подряд.
592, но я не web программист, думаю простительно.
Список хороший, но получив такое на собеседовании, я предложу уволить архитектора. Потому что в теории это все выглядит красиво, а на практике смесь из нескольких php фреймворков и других языков программирования. Да еще и erlang. И зоопарк из ОС. И еще зачем-то указание Linux, после двух разных дистрибутивов.
Оно вам точно все вместе надо?
Если это web студия, пишушая на заказ, тут другой вопрос конечно, да.
Список хороший, но получив такое на собеседовании, я предложу уволить архитектора. Потому что в теории это все выглядит красиво, а на практике смесь из нескольких php фреймворков и других языков программирования. Да еще и erlang. И зоопарк из ОС. И еще зачем-то указание Linux, после двух разных дистрибутивов.
Оно вам точно все вместе надо?
Если это web студия, пишушая на заказ, тут другой вопрос конечно, да.
Не нашёл как прямо там написать комментарий, поэтому напишу сюда.
По ООП:
final — это, может быть ключевое слово из Java, Kotlin, C++ и наверняка из каких-то других языков. Надо, наверное, уточнять язык. А то непонятно.
attribute — может быть из C#, C++, Rust, наверное ещё откуда-то. Может быть общее поняти из ООП.
Короче, есть рац. предложение уточнять откуда понятие.
По ООП:
final — это, может быть ключевое слово из Java, Kotlin, C++ и наверняка из каких-то других языков. Надо, наверное, уточнять язык. А то непонятно.
attribute — может быть из C#, C++, Rust, наверное ещё откуда-то. Может быть общее поняти из ООП.
Короче, есть рац. предложение уточнять откуда понятие.
мне в руки попался интересный документ, который не даёт успокоиться до сих пор. Он мешает мне поставить самому себе 100% владения айтишными хард и софт скилам.
Вот это на мой взгляд очень важно для любого разработчика. Не придти в состояние уверенности «всезнания» или почти «всезнания». Встретить что-то (книгу, анкету, статью, доклад, не суть важно), что покажет тебе, что на самом-то деле ты ничего не знаешь. Что в казалось бы изученной тобой вдоль и поперек области еще столько всего, что даже непонятно, с какой стороны начать все это изучать. И не забывать про это в дальнейшем. У меня лично это была книга Andrei Alexandrescu «Modern C++ Design: Generic Programming and Design Patterns Applied» после первых же глав которой я с очумелым видом, понял, что вообще ничего не знаю о C++
Когда оценка знаний по технологиям и программированию сводится к знаниям фреймворков — это тупиковая ветвь развития.
Жизненный цикл у них с каждым новым всё меньше и меньше, не говоря уже о разнообразии, которые выражается не только в синтаксисе, но и в походе к решению задач в целом.
Простой пример:
Сегодня ты знаешь Angular — завтра его не стало. Тебя на свалку.
Сегодня ты знаешь JS — завтра не стало Angular. Ты до сих пор знаешь JS.
Хотя если не стало JS, то копаем глубже к знаниям основ программирования, алгоритмов.
Мысль: Жизненный цикл ЯП выше чем фреймворков.
Если ты не знаешь/не сталкивался/не работал с Ember, Backbone или ещё каким фреймворком, то это не значит что ты не знаешь JavaScript.
Жизненный цикл у них с каждым новым всё меньше и меньше, не говоря уже о разнообразии, которые выражается не только в синтаксисе, но и в походе к решению задач в целом.
Простой пример:
Сегодня ты знаешь Angular — завтра его не стало. Тебя на свалку.
Сегодня ты знаешь JS — завтра не стало Angular. Ты до сих пор знаешь JS.
Хотя если не стало JS, то копаем глубже к знаниям основ программирования, алгоритмов.
Мысль: Жизненный цикл ЯП выше чем фреймворков.
Если ты не знаешь/не сталкивался/не работал с Ember, Backbone или ещё каким фреймворком, то это не значит что ты не знаешь JavaScript.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Навыки на 100%, а лучше меньше