Pull to refresh
54
0
Андрей Майоров @AndrewMayorov

Frontend developer, architect

Send message
«partial» — пакость, но с ним ничего сделать нельзя. Ограничения технологии. Но и привыкнуть можно, ничего.

А насчет того, конструктор делает что-то еще, то это можно решить как-то так:
  1. Сделать дефолтный конструктор, оперирущий зависимостями, как будто они уже проинициализированы. Для чистоты концепции сделаем его приватным.
  2. Вызвать конструктор в конце другого конструтора нельзя, но можно скопировать его код и добавить в конце сгенерированного.
В этой статье ситуация объясняется довольно подробно. Я лично не копал глубже, но описанное тут выглядит реальным.
www.wetheweb.org/post/cancel-we-the-web
К сожалению, квантовая запутанность не позволяет обмануть вселенское ограничение и передать информацию быстрее скорости света.
Хороший пост, спасибо! Не так давно тоже задумывался над недостатоками системы «лайков» в Фейсбуке. Сейчас каждый день под большим количеством новостей хочется поставить фейспалм. В смысле «боже, ну и идиоты». Но остается только ставить красную морду, со всеми вытекающими последствиями описанными в статье. То есть доподлинно непонятно, что ты имеешь в виду — новость не нравится или автор или событие. (Конечно, с фейспалмом та же проблема была бы...)

То есть с одной стороны может показаться, что в Фейсбуке маловато иконочек, надо бы еще добавить. А с другой стороны есть системы с полной свободой самовыражения (добавляй любой эмоджи), и там уже ничего не ясно. Что значит эта реакция? Ну то есть ты сначала выбираешь пять минут, что бы такое сюда поставить, а потом тебя все равно не поняли.

При этом я считаю, что такие быстрые реакции — это очень важное изобретение (именно изобретение). Они позволяют быстро понять отношение аудитории к куску информации. В чем-то это более важно, чем комментарии. Тут вот в комментариях пишут, что, дескать, не надо дурацкие лайки ставить, а надо комментарии писать, как все нормальные люди. Но вот есть у тебя 100 комментариев типа "+1" и «КГАМ» — кто через это все будет пробиваться? Хорошо спроектированные лайки позволяют предагрегировать мнения, и это очень важно в современных условиях избытка информации.

Вот я над этим думал и мне кажется, что решением будет выработка некого стандартного словаря комбинаций смайликов. Например: «согласен + смешно», «не согласен + глупость», «обман + смешно». Может быть до трех смайлов в комбо.

И я не думаю, что может взлететь какой-либо проект по рейтингованию материалов. Это уже надо, чтобы владелец сайта захотел подключить внешний сервис, вместо реализации своей системы лайков. Зачем это им?

А вот разработка и популяризация такого вот стандартного «языка» — это кажется более перспективным занятием. Если тут вообще есть перспектива, то она в приучении людей к этой идее. А там и Фейсбуки подтянутся (может быть).
Pro tip:
Если избегать слов «инновационный», «уникальный» и так далее, то ваша статья будет меньше похожа на заметку из газеты «Правда».
Если маски станут массовыми, то в маске будут забирать сразу. Выход — маска, которая не вяглядит как маска. 3D-печать + алгоритмы генерации несуществующих лиц помогут сделать вас другим человеком.

Референс про печать масок: 3dsourced.com/interviews/hyperflesh-3d-printed-mask
Имеет все равно. Эта «сложность» — условие, по которому мы выполняем первую или вторую функцию — не относится к самой функции. Если вы затолкаете проверку внутрь, то вы усложните функцию без причины.
Хорошая статья, спасибо! Причем сама статья не так важна, как количество ненависти в каментах. Такого количества «хозяин лучше знает», «не высовывайся» и «ты что здесь, ..., самый умный?» я давно не видел.
Начинающему любителю лучше избегать подобных тем, как черту — ладана. Это не фундаментальное, и никак не поможет вам лучше проектировать.
Вроде как, ваш вариант сложнее в использовании, ибо здесь нужно на каждый action определить тип и написать фабричную функцию. А у Дмитрия пишется только фабричная функция.
Visual Studio Code, например, мало чем отличается от обычного текстового редактора. Грузится мгновенно, никаких особых файлов конфигурации не требует. Но код в ней писать гораздо удобнее, чем в «условном ноутпаде». Подсветка синтаксиса, очепяток. Зачем себя искусственно ограничивать?

Насчет разделения вьюх и контроллеров — любой код хорошо читается, пока его мало. Как только появляется скроллинг, становится заметно сложнее. При этом несколько маленьких получаются гораздо удобнее, чем один большой.
OK, point taken. Но все равно, мне кажется, что на этом этапе развития обсуждаемого проекта лучше начать с простого.
Я имею в виду, что CSS лучше держать во внешнем файле.
Направление мыслей правильное, но:
а) Нет смысла делать все «врукопашную». Лучше взять Ангуляр и сосредоточиться на контролерах и шаблонах страниц для вашего приложения, а не на инфраструктуре.
б) Лучше не объединять контроллер и вьюху в одном классе, а разделить. Тогда у вас получится две иерархии: контроллеры и вьюхи. Как правило, одному классу контроллера соответствует одна вьюха, но могут быть исключения.
в) Так лучше не просто выводить HTML строкой, а сделать простой билдер HTML из дерева объектов. Тогда можно будет при необходимости модифицировать ветку элементов, созданных базовым классом.
г) Стили однозначно должны жить снаружи.

Ну и вся эта «философия пуризма», приведенная вначале — только чистые JS, HTML, SQL, whatewer — это не повод для гордости. Лучше переосмыслить.
Поддерживаю. # — ужасная идея. Лучше не иметь приватных полей, чем иметь их такой ценой.
Хорошее выступление. Хотя не понравилось традиционное упоминание «композиции вместо наследования». Почему бы не использовать этот тезис в его правильной трактовке: иногда вместо наследования лучше применять композицию?

Еще момент: разбиение фасада на кусочки пройдет легче, если вообще не делать фасадов из нескольких методов. Пиши каждый метод в отдельном классе и будет щасте.
Есть и такой вариант — опытный программист делает иерерхию, а остальные ее используют. В этой ситуации большинство людей в команде тратят существенно меньше времени, потому что следуют уже заданным шаблонам, а не лепят свой велосипед. К тому же, код у всех получается более-менее одинаковый, что упрощает поддержку продуктов командой.
Да полно их! Посмотрите хотя бы на голосовалку за эту статью. Я также заметил, что у автора вначале карма была ненулевая.
1
23 ...

Information

Rating
Does not participate
Location
Amsterdam, Noord-Holland, Нидерланды
Date of birth
Registered
Activity