А вы не думали вынести эти статьи в индексированный справочник?
Думаю, если Вы осилите это дело, Ваш ресурс будет очень и очень популярным. :-)
P.S. Хотелось бы еще разделения между официальным API и особенностями реализации на текущий момент, не входящими в официальный API. Для написания кросс-версионных плагинов это достаточно важный пункт.
Думаю, вы согласитесь, что если статья для нубов, то имело смысл разжевать, чтобы не было двусмысленностей. А еще лучше — написать хороший пример. И в ориентированных на новичков статьях не место предположениям — все должно быть предельно ясно.
А если статья для профи — опять же, можно меньше воды и больше конкретики с пруф-линками. А так ни то ни се. Либо отсутствует глубина понимания, и не следовало писать статью, либо автор не умеет последовательно и полно излагать мысль — тогда имеет смысл доработать с учетом комментариев.
И еще совет автору статьи: указывайте в начале статьи вашу целевую аудиторию! Избавите себя от кучи негатива :-)
IMHO, «immutable'ны» звучит лучше, чем «иммутабельны».
Хотя бы показывается, что влом переводить, и поэтому используется англоязычный термин.
А второй способ — просто издевательство над русским языком.
Где еще про такие технологии расскажут, как не на хабре
Базовые — в книжках.
Остальные — на сайтах соответствующих проектов и в тематических блогах.
Хабр — это все-таки не системное изложение, а «по вершкам», больше для информативности. Конечно, есть отдельные хорошие статьи, но нет систематического изложения крупных порций материала.
Да почему ж ) можно и более простые вопросы.
Например, попробуй ответить, почему ручки у сумок для ноутов часто делают на кольцах, вместо того, чтобы сделать просто пришитую ручку?
Java.
Если не компилировать, не запускать и не тестировать — тогда зачем вообще писать?
И вообще, не вижу связи между моим комментарием и вашим. Может, поясните?
Хороших менеджеров реально очень мало.
У меня сейчас начальник отдела — лучший среди всех начальников, которые у меня были.
С моей стороны все его решения выглядят прозрачными и правильными при учете всех факторов, которые мне доступны.
Также отдельной статьи заслуживает разруливание конфликтов, переход с эмоций на здоровую аргументацию.
IMHO, очень сложная в эмоциональном плане работа.
Хотя, если честно, видя такой пример перед глазами хочется научиться этому. Не для того, чтобы руководить — в первую очередь для самоорганизации и понимания причин и следствий.
У асфальта, как у любого физического элемента, есть эффект изнашивания.
Код не изнашивается. В нему данный критерий неприменим без хорошей аналогии.
Может «изнашиваться» (как синтаксически, так и семантически) только код на границе интерфейсов с внешними системами (включая ОС) при развитии этих систем.
Работа программистов состоит в удовлетворении требований заказчика. Заказчик платит деньги за исправление ошибок или за добавление нового функционала. При этом если заказчик является фактическим потребителем продукта, то доля нового функционала достаточно быстро уменьшается. Поэтому остро встала бы проблема поиска новых заказчиков.
Думать надо сразу.
Но жертвовать понятностью кода для повышения производительности нужно только тогда, когда это реально неоходимо. В остальных случаях достаточно заложить возможность дальнейшей оптимизации. В этом очень помогает инкапсуляция алгоритмов.
Большинство, как правило, об этом просто не задумываются.
Думаю, если Вы осилите это дело, Ваш ресурс будет очень и очень популярным. :-)
P.S. Хотелось бы еще разделения между официальным API и особенностями реализации на текущий момент, не входящими в официальный API. Для написания кросс-версионных плагинов это достаточно важный пункт.
А если статья для профи — опять же, можно меньше воды и больше конкретики с пруф-линками. А так ни то ни се. Либо отсутствует глубина понимания, и не следовало писать статью, либо автор не умеет последовательно и полно излагать мысль — тогда имеет смысл доработать с учетом комментариев.
И еще совет автору статьи: указывайте в начале статьи вашу целевую аудиторию! Избавите себя от кучи негатива :-)
Хотя бы показывается, что влом переводить, и поэтому используется англоязычный термин.
А второй способ — просто издевательство над русским языком.
Базовые — в книжках.
Остальные — на сайтах соответствующих проектов и в тематических блогах.
Хабр — это все-таки не системное изложение, а «по вершкам», больше для информативности. Конечно, есть отдельные хорошие статьи, но нет систематического изложения крупных порций материала.
И еще можно играть на его косяках.
А вопрос, скорее, даже не на логику, а на поиск решений в нестандартном контексте.
Умирание нешвейцарских бабушек не в счет!
P.S. Простите, не удержался :-)
Например, попробуй ответить, почему ручки у сумок для ноутов часто делают на кольцах, вместо того, чтобы сделать просто пришитую ручку?
Если не компилировать, не запускать и не тестировать — тогда зачем вообще писать?
И вообще, не вижу связи между моим комментарием и вашим. Может, поясните?
Я имел в виду покрытие сценариев функционально/приемочными тестами.
У меня сейчас начальник отдела — лучший среди всех начальников, которые у меня были.
С моей стороны все его решения выглядят прозрачными и правильными при учете всех факторов, которые мне доступны.
Также отдельной статьи заслуживает разруливание конфликтов, переход с эмоций на здоровую аргументацию.
IMHO, очень сложная в эмоциональном плане работа.
Хотя, если честно, видя такой пример перед глазами хочется научиться этому. Не для того, чтобы руководить — в первую очередь для самоорганизации и понимания причин и следствий.
Код не изнашивается. В нему данный критерий неприменим без хорошей аналогии.
Может «изнашиваться» (как синтаксически, так и семантически) только код на границе интерфейсов с внешними системами (включая ОС) при развитии этих систем.
Работа программистов состоит в удовлетворении требований заказчика. Заказчик платит деньги за исправление ошибок или за добавление нового функционала. При этом если заказчик является фактическим потребителем продукта, то доля нового функционала достаточно быстро уменьшается. Поэтому остро встала бы проблема поиска новых заказчиков.
Но жертвовать понятностью кода для повышения производительности нужно только тогда, когда это реально неоходимо. В остальных случаях достаточно заложить возможность дальнейшей оптимизации. В этом очень помогает инкапсуляция алгоритмов.