• Microsoft начала продавать HoloLens 2 по цене $3500 за штуку
    0

    Powerbank

  • Состоялся первый в истории выход в открытый космос двух женщин
    0

    Про выход гетеросексуальных пар уже писали?

  • Распределённый чат на Node.JS и Redis
    0

    Зависит от восприятия. Можно понимать как немецкий почтальон докладывает, что у вас 4 непрочитанных сообщения. Развенулся спиной, и показал почтовый ящик

  • Первая демонстрация TypeScript
    0
    d.ts генерится компиляторм, а библиотеки не задумывающиеся о ТС продолжают о нем не задумываться.
    Нагрузки вообще никакой нет. Если пользоваться нормальными обычными инструментами, то пользу от ТС зацениваешь уже через несколько часов после того, как начал на нем писать.
  • О главном инструменте разработчика, аналитика и руководителя
    0

    Короче, без пруфов :-)

  • О главном инструменте разработчика, аналитика и руководителя
    0

    Это что получается, надо купить книгу, чтобы посмотреть ссылки на пруфы? Совсем не реклама

  • Обновления от Boston Dynamics
    0

    Впечатление буд-то прыгает за счет реактивной тяги, а не толчка

  • Безлимитное распознавание речи. Или как я перевожу в боте голосовые сообщения в текст
    +2

    Спасибо, полезная статья

  • Цена JavaScript
    +1

    Спасибо за перевод

  • HR-робот обзванивает тысячи людей одновременно: рассказываем, как
    0
    Звонок заключается в том, что вдруг видишь у себя Missed call и голосовое сообщение типа: «Ищете ли вы работу?». Штук 5 таких получил за предыдущие две недели
  • Четыре типажа программистов
    +1
    Правильный тимлид-делец сказал бы: «Давай по-новой Миша, все #@йня. Нам за это денег не дадут»
  • Российские девушки в Data Science
    +3
    Опять сексизм
  • Аутизм и мозг
    –1
    Типичное неумение считывать намеки. У вас аутизм третьей степени :)
  • Дзен не позвонит
    +1
    Redux действительно непросто использовать в средних и крупных проектах, особенно когда бизнес-аналитика часто меняет свои решения по поводу функционала дизайна и пр. Поэтому, все эти примеры из туду листов и генераторы бойлерплейтов не особо работают в таких проектах. Так же сложности добавляет тот факт, если работает над проектом не один человек, а 4-5-n. Тогда эти бесконечные гигабайты шаблонного кода с action_types, actions и reducers точно начнут сводить с ума, если с ними ничего не придумать.
    Один из вариантов решения проблемы, который к слову работает в продакшне, среднего+ проекта, частично решает вышеописанные проблемы https://github.com/welljs/react-redux-mvc. Может показаться, что с паттерном mvc погорячился, но идея именно в том, чтобы довести фреймворк до состояния близкого к mvc

    Принцип прост: компонента react (view) — тупо рисует то, что получила через props от Model. Model — обертка вокруг redux, это то место где формируется грубо говоря json-представление прикрепленной к ней вьюхи, Controller — связывает model и вью, а так же обрабатывает ui-события.

    Структура проекта получает следующий вид
    /classes - классы для работы с данными
    
    /components - компоненты. тупые умные, не важно. компонуются по принципу - все что нужно компоненте, лежит в ее директории
    
    /layouts - лэйауты - с сайдбаром, без сайдбара, логин, лэндинг ...
    
    /pages - страницы, и компоненты принадлежащие конкретной странице. Также компонуются по принципу, все что нужно лежит в одной директории. Если компонента становится общей для нескольких страниц, обычно достаточно Ctrl+X -> Ctrl+V в папку с компонентами. Умная IDE пути в импортах сама исправит
    
    /redux - экшны для получения данных не имеющих привязки к конкретной вьюхе, например user, agreements, partners
    
    /utils - всякое
    


    Из плюсов: сравнительно легко объяснить принцип работы, дебажить, тестировать, компоновать-перекомпоновывать, шарить компоненты и т.п.
    Из минусов: все еще приходится писать немного шаблонного кода, есть небольшие недоделки и не полностью реализован весь замысел

    Если кому станет интересно, буду рад почитать отзывы, а если вдруг даже появятся контрибуторы, тогда точно буду знать, что проект годный
  • Программист ли я, или просто хорошо гуглю?
    0
    Чаще всего я гуглю тексты ошибок и куски стектрейсов… И никогда — чужой код

    А так же сравнительные тесты технологий, фреймворков и т.п. И никогда — чужой код
  • В лаборатории впервые выращен двухнедельный человеческий эмбрион
    0
    Дополню еще, что паразит не будет заботиться о жертве в старости
  • 7 причудливых исторических способов достижения поразительной продуктивности
    +3
    Комментарий тоже, не особо-то и полезен
  • Способы организации CSS-кода
    +1
    На сколько мне известно, использование id или class влияет на поиск элемента в DOM и соответственно на производительность. Так как предполагается, что id уникален в пределах документа, то при поиске по id, браузер останавливает поиск как только находит нужный элемент, а при поиск по классу он производит поиск пока не проверит все элементы в DOM, даже если нужный элемент был единственный, и найден в самом начале. Поэтому использовать нужно и то и другое, в зависимости от ситуации.
  • Повесть о том, как студентики за ночь сайт запилили
    0
    Уже ~30К собрали, если верить прогрессбару :)
    Но вопрос в другом: как долго можно работать в таком режиме? неделя? месяц? год? всегда?
  • SummaryJS, выпуск 5
    0
    Вот например: EmberConf 2015 — Видео плейлист с конференции EmberConf 2015.
    Уже ясно что это видеоматериал, и если ты, в данный момент читаешь со смартфона, то не очень удобно будет его просматривать
    P.S. Там написано, что это видео, не обратил внимания. Но идея все равно хорошая )
  • SummaryJS, выпуск 5
    +1
    Предлагаю помогать автору писать комментарии к тем или иным статьям/библиотекам и т.п., на которые ведут ссылки. Многие ведь заходят и читают что там, и после этого вполне смогут оставить свое мнение в личку автору. Это снизит нагрузку с автора, а остальным читающим действительно легче будет ознакамливаться с материалом по комменту к ссылке.
  • Как распутывать лапшу, не впадая в депрессию
    0
    Спасибо за минусы, приму их как знак внимания. Обосную тем кому все таки интересно. Во-первых плохой тон обращаться к свойствам напрямую — это одно из фундаментальных правил программирования. Например, тут или тут тут мнение авторитетов. Во-вторых, работать можно не только в одиночку — и когда работаешь в команде, то сложно отвечать и контролировать чужие действия, а если команда находится в разных городах, а то и часовых поясах, то еще сложнее. Поэтому если ты используешь чье-то свойство, то лучше избегать прямого обращения к нему, а пользоваться геттерами и сеттерами, потому-что «хозяин свойства» в любой момент может что-то изменить или зарефакторить и в этом случае, он не обязано спрашивать чье-то мнение. Сюда же можно добавить то, что даже когда сам начинаешь проект, то должен понимать, что статика может меняться много-много раз, и для того чтобы не править всё и везде, легче править в двух местах — в геттере и сеттере.
  • Как распутывать лапшу, не впадая в депрессию
    0
    Прощу прощения за опечатку: Надо либо в базовой вьюхе назвать метод frag, либо в наследуемых вызывать как this.frg()
  • Как распутывать лапшу, не впадая в депрессию
    0
    Как вариант:

    //где-нибудь в базовой вьюхе функция которая является и сеттером и геттером. 
    frg: function (name, el) {
    	!this.domElements && (this.domElements = {});
    	return el ? (this.domElements[name] = el, el) : this.domElements[name];
    }
    
    
    // Использование наследуемых вьюхах: 
    
    // в сеттер надо передать два параметра: название и сам элемент. 
    // сеттер так же возвращает закешированный элемент
    this.frag('my-block',  this.$('#my-block')).css({display: 'block'});
    
    // геттер получает один аргумент и возвращает из кеша элемент
    this.frag('my-block').css({display: 'block'});
    

    Довольно стройно и элегантно
  • Как распутывать лапшу, не впадая в депрессию
    –1
    Иногда статичное свойство может измениться, и тогда придется искать его, и править по всему проекту. А в случае с методом, придется изменить свойство только внутри метода, который его возвращает.
  • Собеседование на позицию разработчика, как оно есть
    0
    Поскольку мир IT настолько велик и разнообразен — то придумывать индивидуальные задачи порой очень трудно

    Причем тут мир IT? Вы работаете в конкретной области, и ищите конкретного специалиста, который будет выполнять конкретные задачи. Придумать задачу, когда все конкретизировано проще паренной репы. Если вы засечете время, то заметите, что на придумывание задания, которое соответсвует этой конкретной работе, уйдет не более 15 минут, скорее даже меньше. Но это избавит от утомительных собеседований, которые на 80%-90% трата времени.

    Но поскольку с данной библиотекой мне работать не приходилось, касательно нее я ничего спросить не мог

    А зря, бегло глянув в код, можно понять как человек работает, и если код визуально понятный, то можно вникнуть и понять ход мысли программиста.

    На мой взгляд функции на бумаге и тому подобное позволяет интервьюеру найти с вами общий язык

    С чего вы взяли что вы находите общий язык? Вы часто интересуетесь о том, удобнее ли соискателю написать в IDE или на бумаге, и оба соглашаетесь в том, что на бумаге программировать куда удобнее?

    В общем не думаю, что вопросы такого типа должны сильно смутить квалифицированного разработчика

    Но лучше, наверное, спросить квалифицированного специалиста, не смущают ли его такие вопросы, а не думать за него.

    Вы так и не согласились с тем, что как и другие специалисты, интервьюверы тоже бывают плохие и хорошие, подготовленные и не подготовленные. И как и других специалистов, плохих интервьюверов гораздо больше чем хороших.

    P.S. У меня к соискателям еще одно требование: рассказать смешной анекдот или шутку. Но это так, чтобы понять, как в коллектив вольется )
  • Собеседование на позицию разработчика, как оно есть
    0
    Хочется отметить, что провальные собеседования не заслуга одних лишь соискателей. Если бы собеседующих можно было категоризировать как разработчиков, то бОльшая часть интервьюверов была бы джуниорами, а то и хуже. Скажу от имени более-менее квалифицированного специалиста, который был по обе стороны барикад: это оскорбительно, когда по дороге на интервью ты собираешься с мыслями о том, как проектировать системы, как оптимизировать узкие места, как граммотно организовать работу и как управлять командой разработчиков, приезжаешь, а тебя спрашивают: «что выполняет эта функция» — написанная на бумаге? Это очень оскорбительно, черт возьми! Собеседование и набор персонала — это ответсвенное задание, а большинство относятся к этому более чем легкомысленно. Неужели так трудно придумать задание из текущей работы? Да таких заданий можно напридумывать хоть для каждого претендента в отдельности. Надо только мозгой шевльнуть и тогда легко сможешь определить людей знакомых с нужным стеком технологий, с теми кто быстро осваивает новые технологии, с ходом мысли разработчиков и всем остальным, что необходимо для того чтобы взять на конкретную работу конкретного человека. При всем этом съэкономить время и нервы себе, и соискателю.

  • Well.js – еще один подход к модульной разработке на JavaScript
    +1
    Баги могут быть везде

    Лучше пусть эти баги будут мои.
  • Well.js – еще один подход к модульной разработке на JavaScript
    0
    ES6 Module Transpiler is an experimental compiler that allows you to write your JavaScript using a subset of the ES6 module syntax, and compile it into AMD or CommonJS modules.


    Меня пугают выражения experimental в продакшне
  • Well.js – еще один подход к модульной разработке на JavaScript
    +1
    Как-то надо было срочно решать поставленную задачу, а много времени на изучение существующих решений не было. Самое популярное что было на слуху — Require.js, но с ним я споткнулся, что привело к написанию скорее не велосипеда, а наворотов к нему. На самом деле, у меня обертка над Require.
    Кроме того, я отношусь у группе людей, которые любят изобретать велосипеды, чтобы быть в тонусе :--)
  • Well.js – еще один подход к модульной разработке на JavaScript
    –1
    Да, именно их родная оптимизация показалась сложной. А на счет обертки — интересно, как-то ее упустил. Спасибо