Как стать автором
Обновить
12
0
Иван @bano-notit

Freelancer

Отправить сообщение

Соцсети это не блоги и не аккумуляторы информации. Это просто сервисы общения с вебинтерфейсом. Там нормальные люди ничего не хранят. Скорее просто используют как площадку для публикации.


А вот взять медузу или хабр — ссылки на статью хотя бы остаются всегда рабочими. Вот это уже больше про наследие. Жаль только что хабрасторадж в 8 году не существовал. Многие статьи того времени остались просто без картинок и кажется уже никогда не восстановятся.

Столько раз дебажил минифицированый код… Это кстати очень интересно. А главное познавательно. Тут ничего сложного нет.


Сменяемость можно предотвратить реализовав расширение которое не будет пускать файлы с левым хешем. Правда долго будет такой интернет грузиться. Зато вы точно будете знать когда и что обновилось.


А вот нативный код покрытый каким-нибудь vmprotect — удачи вам.

Простите пожалуйста. Но в русском языке нет понятия драматического снижения нагрузки. А ссылки на оригинал я как-то не нашёл.

Думаю через пару итераций GitHub свернет блок с файлами по умолчанию,

Сомневаюсь на самом деле. Потому что большую часть времени именно как разработчик я захожу в репу за файлами. Во всяком случае в свои рабочие репы я захожу именно за кодом. А если нужно "продать библиотеку", ну у нормальной библиотеки есть сайт, чаще всего ещё и с документацией.


Если GH захочет делать именно showcase, то лучше его отделить за какой-нибудь отдельный режим. Если свернёт файлы для всех реп, то будет больно. Если закроет код у чужих реп, и надо будет просто открывать чтобы посмотреть docs/, будет не оч всё равно.

Всё бы хорошо, но компания Дурова называется Telegraf. А ещё можете сказать откуда у вас магические 72%? И ещё вы человек видимо знающий, можете объяснить бизнес модель самой телеги? А то я вот никак не могу понять откуда в неё деньги вливаются. Выливаются из неё отовсюду, а вот как они попадают туда не очень понятно.

человек, который делает вывод о том, что изучает другой человек исходя из одного комментария

Если вы спроецировали мой комментарий на себя лично, уж простите, но я не к вам обращался, а вообще к людям которые приходят в веб из вот этих статей, думая что наберут вот таких вот pro tips и станут хорошими программистами. А таких к сожалению много, и их шлейф тянется со времен jquery.


И я понимаю, что даже через 2-3 года нельзя зазнаваться и пропускать «новичковые материалы» — это способ избежать «зашоренности»

Держать руку на пульсе совершенно не значит смотреть материалы для новичков. Наоборот, это следить за пропоузалами, смотреть документацию и примеры реального использования новых фич. С обсуждением и осознанием плюсов или минусов определенных фич.


Например при выходе es6 сразу можно было заметить, что часть людей побежали использовать везде промисы, а часть продолжала сидеть себе спокойно на bluebird — консистентность кода важнее хайповых фичей.


Новичок отличается от «зашоренного» профи тем, что не способен сказать почему конкретно он не будет использовать ту или иную фичу. Новичок будет смотреть на новый синтаксис и обтекать слюнями, а профи посмотрит и скажет, что не будет его использовать, потому что в случае чего явисты из соседнего отдела не смогут поправить в коде что-то во время отпуска этого самого профи.


новичок изобрёл новый полезный трюк, просто потому, что не знал, что «это невозможно».

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

Я бы не хотел работать с человеком, который изучает JS по статьям такого качества и настолько разбросанным по тематике. Одно дело когда что-то новенькое или спорное всплывает, вроде недавних immutable set'ов и объектов. Но нет, в этой статье рассказывают ни о чём, да ещё и без нормального объяснения.


Если человек хочет научиться писать на JS, пусть идёт на learn.javascript.ru. Там и контент качественнее и хоть какая-то систематизация информации. А такие вот статьи — просто бред сивой кобылы. Они новичкам только вредить могут, а профи от них только бесятся. Бессмысленная трата времени и читающих, и пишущего.

что женские особи обоих полов склонны

Ребят, хватит делать жёлтые заголовки и при этом писать такие дурацкие тексты! Хабр не торт из-за установки: «в нашем блоге каждый день должна быть статья, чтобы мы постоянно присутствовали в ленте людей». Такая установка ведёт только к ухудшению контента.

Я так тоже смотрел, на панорамах. Всего 2 улицы тогда было и вообще всё выглядило как-то не очень. В этом году потратил денёк зимой и побывал лично. Архитектурно интересно конечно, всё новенькое, всё чистенькое. Но город действительно маленький, мы за час обошли его весь… Больше времени потратили на то, чтобы пройтись до берега, с которого видно Свияжск.


В общем как интересный и "вкусный" на события город, я бы не выбрал, тут скорее Казань подойдёт. А вот как место куда можно уехать от излишних "вкусностей" подходит просто зашибенно.

Игра не кроссплатформенная. На ноутах иногда нет лампочек. Ну и лично у меня только игра на запоминание последовательности придумывается. Правда на 3 сигналах она будет не то чтобы интересной.

Просто коренной комментарий был про использование в React)


На счёт immutable сторов я не очень понял в чём разница с frozen объектами, кроме того, что тут deepFreeze. На уровне интерпретатора замороженные объекты явно имеют какое-то специальное свойство и никто не запрещает v8 или spidermonkey применять оптимизации сравнения для двух frozen объектов.


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

И опять пойдём по пути "заражения"? Как уже было с async/await. Конечно возможность крутая, но для этого нужно переписать очень и очень много библиотек, при этом сильно уменьшив область их применения. А переделывать каждый раз обычных объект в такой вот словарик — кажется дорогим удовольствием. Самое главное, что если нам нужно постоянно для каждого компонента вычищать колбеки и у пропсов переделывать их тип, то легче уже будет делать это всё в самом shouldComponentUpdate.

Петровский док в Кронштадте не является зданием, но как-то он попал и отрисовывается)

Я знаю что это мультик на Питер)


Я только сейчас понял, что у автора на карте даже Петровский док имеет год постройки, а в ОСМ у этого дока даже нет building, он там attraction=urban. В общем, интересно получается)

Туда бы часть Кронштадта не затесалась)

Автор поста свою агрегацию данных выложил под CC-BY-SA. Но ещё не факт что он имеет право выдавать эту информацию так.


Я не помню чтобы данные на основе ОСМа можно было передавать другим без копирайта самого ОСМа.

В ОСМ можно тянуть только открытые источники, которые согласились в ОСМ поучаствовать. CityWalls вроде как разрешил ОСМу брать данные с картинок, но не информацию с самого сайта (если правильно помню там предлагали что-то с превьюшками зданий намутить)


В общем для того чтобы в ОСМ это всё импортнуть надо ещё получить всякие разрешения.


До сих пор не можем получит разрешение на использование Публичной Кадастровой Карты(

Эту штуку нельзя применить в реакте. Потому что в пропсах почти никогда не передаётся только примитив. Во всяком случае во всём коде который я писал, всегда передавались объекты, какие-нибудь map'ы или функции, но чтобы были только строки или только числа — вот такого не встречал почти никогда.

Идея прикольная, вот только её не примут. Самая главная конструкция с этими типами === не имеет никакого специального синтаксиса. Значит транспилировать её не получится. Именно по той же самой причине транспилируемости у нас приватные поля делаются через #, а не свойствами самого поля. Именно поэтому у нас для всего придумывают новый синтаксис такой, чтобы он был чётко отличим от старого...


Приведу пример кода, которого нет ни в одном из примеров в статье и репе предложения:


const a = #[1, 2, 3]
    , b = #[2, 3, 4]

assert(a === b)  # должен быть false

Вот в этом примере явно видно, что на этапе компиляции нельзя понять что будет храниться в a и b, а соответственно нельзя со 100% уверенностью применить обычный оператор === или именно полифил для этой штуки c поэлементным сравнением.


Если же каждый оператор === заменять полифилом, то получится слишком много кода.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность