• Редактор еженедельных расписаний
    0
    Согласен, пример собран из не английского исходника. Почему-то в процессе kabinet в cabinet превратился… В проектах, над которыми работаю, скорость ввода не сильно важна. На первом месте — мощность отображения, наложение любых календарей друг на друга (например, календарь учителя поверх календаря activities), потом подсветка assignments и workshifts других учителей, чтобы было видно, когда данному можно проставить перерыв, на какие блоки его еще можно записать итд.
  • Я сделал API для скриншотов сайтов, а какой-то парень начал майнить через него криптовалюту
    +2
    Есть еще индусы — 1.4$ за 1k успешных, прокси 6$/мес.
  • Почему в Петербурге так сложно построить карьеру VP of engineering
    +1
    Поддерживаю, у меня с crossover пару лет назад не сложилось из-за 40-а часов. Индустрия быстро развивается, чтобы оставаться в теме одного основного рабочего стека едва ли достаточно. Со своими проектами и опенсурсом на работу остается часов 5. Upwork кстати хорошо развивает, если не бояться брать небольшие проекты немного вне своих основных инструментов.
  • Cоздаём компонент карт Google Maps API с помощью VueJs2
    –1
    Почему бы просто не взять vue-google-maps?
  • Зачем нужен БЭМ
    0
    На глобальный search__button--primary тоже можно напороться. Но так да, название длиннее, вероятность меньше.
  • Зачем нужен БЭМ
    +1
    Зачем в модификаторе повторять всю цепочку названия? Моя верстка в общем следует бэму, только все модификаторы, и только они, начинаются с `-` т.е. вместо
    <button class="search__button search__button--primary">
    идет просто
    <button class="search__button -primary">
  • Nuxt.js: 28 килобайт пользы для веб-разработчика
    +1
    В статье вроде написано про серверный рендеринг, но подано это как-то странно, будто бы главным смыслом SSR является подготовка статики для выкладывания ее на CDN через nuxt generate.

    На самом деле, SSR в nuxt — это попытка наконец-таки делать индексируемые динамические сайты (single page applications) + попытка ускорить первоначальную загрузку этих самых сайтов. Грубо говоря, вместо того, чтобы грузить заглушку, которая после инициализации подтянет данные через ajax, эти данные будут подтянуты nuxt-ом на сервере через node, отрендерены и отданы сразу же в шаблоне.

    Насколько попытка удачная — покажет время, обещают скоро выкатить 1.0, пока что все это изрядно глючит, а раз так, едва ли можно положиться на nuxt в продакшене, где эти оптимизации имеют смысл.
  • 5 приемов в помощь разработке на vue.js + vuex
    0
    Наверное, в vuex возможно хранить вообще все переменные приложения, но, на мой взгляд, это — неоптимальный вариант. У меня в vuex хранится только критический минимум важных данных, а компоненты имеют свои собственные локальные данные и события. Они более независимы, лучше живут сами по себе.
    Можно же вообще все в одном компоненте написать.
    Простой пример — вызов модального окошка с настройками, которое вызывается из компонента каждого элемента списка и еще откуда-нибудь.
  • 5 приемов в помощь разработке на vue.js + vuex
    0
    На мой взгляд, между глобальными переменными и глобальной шиной событий есть большая разница. По сути, все redux-mobx-vuex это попытки более безопасного использования глобальных переменных. Как только приложение разбивается на локальные компоненты, над ними всегда висит что-то глобальное, что их связывает. EventEmitter — еще один способ связи, довольно безопасный.
  • Интересный этюд Factorio: симулятор завода
    0
    Проблема масшабирования — главное, с чем нужно разобраться в игре. Поначалу не знаешь, сколько заводов проволоки нужно на сколько заводов микросхем, итд. Но даже когда знаешь все пропорции, зачастую оказывается, что хочешь удвоить производство, а места на заводы/конвееры уже не хватает. Блоки заводов приходится выносить, и все становится слишком сложным.
    Обычно строят центральную шину с основными матариалами, а заводы — ортогонально шине, тогда ряд заводов можно продолжать неограничено.
    Но я сам предпочитаю треугольную расширяющуюся шину. Один конвеер для одного продукта без смешивания. Идея такая:

    image

    Слева направо идут ресурсы, заводы строятся только вверх, ленты конвеера идут 2 через 2 чтобы строить подземные переходы. Отделяешь нужные ветки ресурсов, ведешь наверх, строишь заводы один над другим, результат спускаешь вниз в новую линию.
    Почти все ресурсы строятся не более чем из 4-х компонентов.
    Для самого сложного случая, 4-х компонентов, схема может выглядеть так:

    image

    Ну и полная картинка одной из баз — http://booger.ru/data/2017_07_04/FullSize.jpg
    Игрушка правда уже не новая, сам играл год назад.
  • Чек-лист по выживанию сайта
    +1
    Отличный материал, спасибо. Особенно согласен в плане взаимодействия с базой.
    Буду ссылаться вместо того, чтобы каждый раз объяснять, почему до сих пор пишу все запросы руками.

    В плане базы я бы сделал акцент на то, что большинство систем работают в основном на чтение (1 запись на 100 чтений). Поэтому простота чтения должна быть обеспечена в первую очередь. Академические нормальные формы, например, отношения many-to-many в отдельных таблицах, должны быть продуманы, нужны ли они вообще в каждом конкретном случае.

    5 копеек про фронт: я бы выделил 3 периода: до jquery, с jquery, с mvvm (knockout/angular/react/vue). Если система не в 3-ем периоде и хочет развиваться, то нужно переходить. Внутри mvvm переход едва ли оправдан — несмотря на различную внутреннюю логику, нет ничего на angular/react, чего нельзя написать на старичке knockout в тех же строчках кода и той же сложности. Новеньким я бы советовал vue.js как последователя, который включил все лучшее от предшественников.

    Фанаты реакт хвалятся виртуальным dom-деревом — мол самые затратные операции — операции с dom, поэтому прослойка, которая фильтрует изменения dom, делает реакт очень быстрым. Однако реакт тоже прекрасно вешается, если не думать. А если думать, то любая универсальная прослойка будет медленнее, чем нативный специализированный код, который не делает ничего лишнего.
  • Верстка интернет-магазина: список товаров
    0
    Насчет фото товаров: давно использую технику через background-image и background-size: contain. Мне кажется, она более универсальная — красивее, когда все фотки квадратные, даже если оригиналы вытянуты (предпочтительнее сцентрировать и обрезать выступающие за края части а не вписывать прямоугольники). Типа https://jsfiddle.net/kasheftin/avqdpsgs/. Тег img имеет opacity:0 и нужен только чтобы фотку можно было потащить мышкой.
  • Google дает своему ИИ читать женские романы тысячами. Зачем?
    0
    Лет 15 назад я написал свой автоматический любовный признаватель, на элементарных марковских цепях. Из романов брал только фразы признаний, они отлично подходят для автоматических текстов — мало связаны и хорошо повторяются от текста к тексту. Идейка-то верная была, оказывается.
  • Мыши живут на 25% — 35% дольше, если избавить их от «изношенных» клеток
    0
    Смотрите на это иначе. К сожалению, первыми это применят политики, у которых все схвачено, чтобы остаться у власти на 20-й срок. И не будет ни какой надежды дождаться, когда же очередной Пол Пот склеит ласты.
  • Художественный подход к загрузке изображений
    0
    Черепашки-ниндзя прикольные:)
  • Шесть вещей, которые вы должны знать о движении WordPress в сторону JavaScript
    0
  • Навигатор для людей с ограничениями подвижности (с исходниками)
    0
    Литовский идейный аналог — beslenksciu.lt. Здесь роутинг не так важен, потому что обычно нет проблемы с проездом на коляске. На stops.lt есть так же расписание транспорта, в том числе подходящего для инвалидов. Поэтому перемещение по городу — это не проблема, и суть be slenksčių не в роутинге, а в базе доступных для посещения объектов. Из статьи понял, что был написан свой роутинговый код, почему было не взять готовый?
  • Справочник методов console в JS
    0
    — deleted ---
  • Справочник методов console в JS
    0
    Мне одному не хватает нормальной реализации group в консоли с возможностью дописывания? Чтобы разные части системы могли писать в свои группы не смешиваясь.
  • Мысли вслух о разработке javascript-приложений на примере небольшого Line Of Business фреймворка
    +1
    Спасибо за материал, особенно за after в биндинге для форматирования и пример использования extenderов. Я тоже пишу большие приложения на нокауте, однако совсем не использую примеси и наследование. Пугают большие единые монолитные объекты намешанные из кучи всего. Обхожусь небольшими моделями с обвязкой, которые называю виджетами, и которые общаются друг с другом через eventEmitter. Ошибки в одном виджете меньше влияют на всю систему, чем ошибки в общей примеси. Несколько человек могут писать свои виджеты одновременно в одной системе. Если интересно — github.com/Kasheftin/ko-widget — реп с движком, на котором работают мои последние проекты.
  • Планирование автопутешествий на базе google maps api
    0
    Что требуется от серверной части? Она сейчас есть в виде одного файлика api.php, который сохраняет и выдает сохраненные маршруты (сначала сохранение маршрутов было в localStorage, но потом понадобилось работать с маршрутом с разных компов).
  • Планирование автопутешествий на базе google maps api
    0
    Все верно. И, конечно, главное — гугловый поиск мест и прокладка маршрутов, а все мое — удобная обвязка, чтобы их смотреть.
  • Планирование автопутешествий на базе google maps api
    0
    Это — «советчики и путеводители» путешествий. Далекие от совершенства, судя по тому, что на всю Словению там 3 достопримечательности.
    Мой проект — скорее «редактор и рисователь» по карте.
  • Планирование автопутешествий на базе google maps api
    +1
    Насколько мог, настолько сделал. Следуя вашей логике, не существует ни одного бесплатного опенсурсного текста и кода, если он был написан с использованием нотепада под виндой, поскольку винда не бесплатна и не опенсурсна. Касательно своего кода — ничего не закрывал и не ограничивал.
  • Планирование автопутешествий на базе google maps api
    0
    Маршрут другой, а приключения порой похожи:)
  • Планирование автопутешествий на базе google maps api
    0
    Этой — нет, конечно:) Я бы рассматривал эту штуку как некий редактор, с помощью которого можно набросать рисовать по карте. В дальнем путешествии то что на интернет, и на электричество лучше особо не полагаться. Я обычно распечатываю все контакты всех кемпингов перед путешествием.
  • Как инвестировать $100 000 в собственную карму (часть 1)
    0
    Прошу прощения, откуда эта информация?
  • Как воплотить в жизнь мечту детства и запрограммировать что-нибудь для Dendy
    0
    Как-то решили вспомнить былое на даче и вытащили денди. Блок питания не нашли, но автомобильный аккумулятор вместо него отлично подошел.
  • Будущее глазами Эрика Шмидта: «Новый цифровой мир»
    +3
    Ох уж эти предсказатели. Эрик Шмидт похож на фантаста 60-х, который предсказал через 40 лет колонии на марсе и звездолеты, но забыл про мобильники и интернет. И в итоге люди не летают в космос по тупой причине: это дорого.

    Летать на работу на вертолете — это охрененно дорого.

    Мое предсказание такое — если ситуация с энергией вдруг на порядки не улучшится, эта дороговизна будет играть все большую роль. Я уже 5 лет работаю удаленно и вижу, что такая жизнь гораздо дешевле. Это +3 часа времени (не надо ехать и собираться) — а значит еще одна работа на пол ставки, это здоровое и дешевое питание дома итд. Вроде как халява заканчивается, экономия во всем становится естественной.

    Успешный богатый европеец будущего — это человек, который живет где-то поюжнее (не задумываться о погоде), в небольшом городе (дешевле) в пассивном доме с толстыми стенами (не платить за отопление), без всяких будильников (все равно коллеги разбросаны по временным зонам), имеет машину начала века для поездки в супермаркет (главное что ездит), в мыслях и увлечениях достаточно ограничен. В условиях глобализации быть востребованным означает разбираться в своем деле лучше всех, а значит на остальное уже нет времени, денег и мозгов.
  • Топология для самых маленьких. Часть 2
    +6
    imageimage
  • Быстрые треки на google maps
    0
    Шутка в том, что разница набегает из-за внедрения отладки. Пока ее нет, в том коде, что в статье, разница едва ли будет заметна.
  • Быстрые треки на google maps
    0
    Leaflet для векторной графики по умолчанию использует svg, то есть не подходит для анимации. Лефалетовский канвас для анимации тоже не подходит, причина в тормозах при перерисовке слоя. OpenLayers не знаю. Но вообще у меня сомнения, что существует решение из коробки, которое отрисовывает треки быстрее, чем мой код. Большинство приемов не зависит от движка: канвас все равно создавать самому. Рисовать — тоже самому. Следить за перерисовкой. итд.
  • Делаем «mindmap» на Javascript с локальным хранением в базе данных браузера
    0
    Мда, код еще тот. Вдогонку:

    Определитесь с тем, насколько универсальным ваш код должен быть. Синглтон по надобности — одна из последних вещей. Если предполагается встраивание вашего кода в какой-то внешний неизвестный код, то первое, что надо — оборачивание всего этого добра в локальный контекст. Смотрите require.js. Второе — destroy-метод. Наподключали обработчиков, а убирать за собой кто будет?

    Половина кода — jquery-навешивание обработчиков на глобальный dom. Если код претендует на универсальность, это нужно убрать.

    Бэкбон здесь на мой взгляд излишен — это одностраничное приложение без роутинга и особого контроллера. Берите knockout.js.

    Для удаленного редактирования файлов посмотрите в сторону sshfs.
  • DarkJPEG: cтеганография для всех
    0
    Суммарное число пунктов выросло до 13, и идея потерялась в них окончательно.
    Сервис в качестве картинки-донора грузит фото из google images. Я всего лишь предположил, что неограниченным источником неинтересных разных изображений может служить поток с вебкамеры. Или вебкамер. Эдакий сервис «дай мне скучную фотку», который имеет список линков на несколько тысяч живых вебкамер по миру и отдает случайный кадр с одной из них. Это несоменно проще, чем принуждение пользователя делать снимок камерой (которая у него не обязательно есть вообще) на КАЖДОЕ сообщение (данное требование присутствует в третьем пункте Вашего списка).
  • DarkJPEG: cтеганография для всех
    0
    Ваш список из пяти пунктов несомненно проще, чем поток с камеры.
  • DarkJPEG: cтеганография для всех
    0
    Генератором осмысленных картинок наверное может быть поток с вебкамеры, направленной на улицу на дерево что-то еще постоянно меняющееся?
  • Пистолет «Освободитель»: 100 тысяч скачиваний за двое суток
    +6
    Не, не так. «Террористы пронесли в салон самолета мини 3D принтер, в салоне распечатали оружие и угнали самолет».
  • Пишем сложное приложение на knockout.js — 2
    0
    На сервер сайде много всего. Само собой, площадка имеет доступ к базе сети через api. При публикации контента, специфичного сайту, площадка отправляет в сеть сниппет, который появляется в лентах друзей пользователя. Кроме того, некоторые блоки сети могут быть запрошены через api и отданы страницей сайта как статичный html.

    Меню нужно чинить.
  • Пишем сложное приложение на knockout.js — 2
    0
    Какие либы вы готовы грузить чтобы его использовать? Грузить нокаут ради одних только окон мало кто захочет. Можно конечно все на jquery переписать, но там нет ни одной идеи. И тогда уж стоит взять за исходник оригинальный js от бутстрапа и допилить что требуется, он вполне здраво написан.
  • Парсинг сайтов-магазинов. Личный опыт и немного how-to
    +1
    Для PHP есть PHPQuery, она поддерживает как xpath, так и селекторы в стиле jquery. Это если кто-то пишет парсеры на php.

    Насчет админки — все понятно, тоже с подобной структурой работаю, только у меня еще правила бывают вложенными. Т.е. товары из разных категорий имеют разные правила для определения своих свойств. Это полезно, к примеру, когда парсишь базу автомобилей, и там встречается множество модификаций моделей авто, и их практически нереально сопоставлять без знания, какая же у авто модель. То же самое с базой недвижимости по мелким городкам Европы — гораздо проще сопоставить город, если уже известны страна и регион.