• Вред маленьких функций
    0
    Функции не должны быть ни маленькими, ни средними, ни большими.
    Они должны быть понятными.
    Размер — это средство, а не цель. Но многие это путают.
  • Комментарий из публикации, перенесённой в черновики.
  • Комментарий из публикации, перенесённой в черновики.
  • Нейросетевая игра в имитацию
    +1
    порождающие совернующиеся сети
  • Твердотельные накопители Samsung: набирая обороты
    +1
    Спасибо, вопрос снят :)
  • Твердотельные накопители Samsung: набирая обороты
    0
    А что тогда значит трех в трехбитная память? :)
    И откуда взялось 7?
    Почему не 12? :)
  • Твердотельные накопители Samsung: набирая обороты
    0
    Время идет, все вокруг меняется и технологии — не исключение.

    Может слишком капитанский тезис? :)
    Как раз технологии летят, что остальные не всегда успевают за ними меняться :)

    48-слойная трехбитная память ТLC

    Ого.
    Имеется в виду троичная логика?
    Или все же 3 ячейки по 1 двоичному биту? :)

    П.С.
    Статья показалась какой-то маркетинговой :)
  • Редизайн Хабрахабра и Гиктаймс. Финишная прямая
    0
    Мне кажется, вы упустили об этом в статье… :)
  • Редизайн Хабрахабра и Гиктаймс. Финишная прямая
    –1
    deniskin
    +100500
  • Редизайн Хабрахабра и Гиктаймс. Финишная прямая
    +2
    Увеличили кегль шрифта. Не потому, что у нас появились проблемы со зрением, а потому, что сейчас это вполне правильный тренд современной веб-типографики, да и многие из вас не раз жаловались на мелкий шрифт.

    Жить в тренде — значит не иметь собственного мнения.
    Об адаптивном дизайне не слышали?
    На многих сайтах есть кнопочки для уменьшения/увеличения шрифтов…

    П.С.
    Зачем в этом поле такой большой левый padding?

    П.П.С.
    Мне кажется, упустили индикацию «Вы подписаны/не подписаны на этот хаб».
    Или это давно было? :)
  • Безопасный OpenVPN на VPS за несколько минут
    0
    Как обойти «Определение туннеля (двусторонний пинг)» кроме покупки сервера в одной стране / городе?
  • Где лучше всего жить и работать разработчику
    –11
    Зачем всякое дерьмо тянуть сюда и переводить?
  • Ruby on Rails для разработки маркетплейса
    –1
    Ниачем :)

    Для разработки с нуля используются различные фреймфорки

    Если квалификации хватает, то можно и на голом языке (PHP). В нем есть все нужное. :)
  • Руководство для начинающих по прогрессивным веб-приложениям и фронтенду
    0
    Не, мне просто интересно, какие задачи React решает на самом деле :)
    Из-за чего такой хайп.
  • Руководство для начинающих по прогрессивным веб-приложениям и фронтенду
    0
    Вся суть реакта — это возможность писать кашу из html и js при том, что html без кавычек? :)
    Вы из-за этого его используете?
  • Petya.A, Petya.C, PetrWrap или PetyaCry? Новая вирусная угроза для компаний России и Украины
    +2
    А где можно скачать вирус? :)
  • Рихард Цвиненберг (AMTSO): “Киберпреступность не имеет границ, но мы застряли с национальными законами…»
    0
    Похоже, что сегодня наблюдается намного больше атак, чем когда-либо ранее…

    А ниче, что сейчас намного больше компов и прочей техники, чем когда либо? :)

    Хотя собственно это и ответили. :)

    Учитывая развитие компьютерных угроз, есть ли у кого-то сегодня возможность самому разработать эффективное решение безопасности?

    Тоже вопрос возникший из ниоткуда. :) Прелюдия не предполагает этого вопроса. :)

    По Вашему мнению, кто должен быть более заинтересован в совершенствовании своих знаний об ИТ-безопасности?

    Какие знания? Как работает вирус? Это задача ИТ-директора, СБ, директора за неимением первых позаботится о наличии файервола и антивируса. Детали знать не нужно.
    Всем остальным, по большому счету, плевать на ИТ безопасность. :)

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

    В Украине плевать на обычные преступления, не то что кибер. :)

    AMTSO

    Это тут антивирусы тестируются?
    Или типа софт сертифицируется, что у них нет зараз? :)
  • ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет
    0
    Есть еще построитель запросов. :^)
    Но не нужно надеятся, что он сможет (легко) сконструировать сложный запрос. :)

    Я иногда сложноватый запрос изначально пишу в sql, а потом уже транслирую для построителя запросов на языке программирования. :)

    То есть sql-код не пишется вручную прежде всего потому, что неудобно работать с сырым текстом в языке программирования.

    Если придерживаться логичного форматирования sql-кода, то нету ничего сложного в его написании, да и размер кода в чистом sql скорее всего будет меньшим. :)

    ORM — как бы чуть для другого, оно даже расшифровывается для чего оно. :)

    Ну такое, не всем дано понять. :) Особенно теперешней аудитории хабра.
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 1: собираем стек
    0
    Я сам уже не помню, что вкладывал в то, что Вы процитировали. :)
    Возможно я что-то недопонял. :)
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    Так и на jquery можно писать в таком извращенном стиле :)
  • Фреймворк для простых проектов на jQuery
    –1
    Ты просто ниасилил :)
  • Стать руководителем (в плане назначения должности) и быть им (по факту) – задачи разной сложности
    0
    Хм.
    Непосредственный руководитель (тимлид) не использует никаких кнутов и пряников. Он как старший коллега.
    Начальство повыше к нам (разработчикам, с тим-лидом общаются) практически не лезет.
  • Какие перспективы у Node.js после воссоединения — мнения экспертов
    +1
    Примерный диалог:
    Новичек: Где получать информацию о веб-программировании?
    me: Читайте хабр.
    Программист: В массе стадо студентов, ламерья. Сейчас из двух десяток заметок — одна стоит внимания. Лучше читать профильные форумы, а хабр в качестве желтой прессы во время кофе с бутербродом.
    me: Кстати да. Еще очень самоуверенного.
  • Микросервисы: пожалуйста, не нужно
    0
    1. А я и не говорил, что я не могу ошибаться. Перечитайте пункты 2,3, адресованные предыдущему оратору.
    2. Люди, которые знают, что делают, конечно же есть. Я этого тоже не отрицал :)
    Но не все то золото, что блестит:

    Например.
    То, что проект большой, не значит, что он умно сделан (тем более во всем). :)
    Посмотрите для примера на богомерзкую мордокнигу.
  • Микросервисы: пожалуйста, не нужно
    0
    1. Я тоже помню (фрагментарно) :)
    2. Не нужно ничего доказывать. Я не стараюсь что-то доказать. Я стараюсь найти аргументацию, что для чего в каких случаях больше подходит, в каких случаях А может быть лучше Б, в каких нет.
    В данном случае — в каких случаях и как стоит использовать микросервисы.
    3. Если я в чем-то ошибаюсь, приводите аргументы. Но не детский лепет, который разбивается в пух и прах. (Это не только вам адресовано). Если укажете на ошибку, я будут только благодарен.

    >Мой личный проект в среднем обрабатывает 10к запросов в секунду, думаю, на этом можно закончить :D

    Ну это совсем другой разговор. :)
    Мало какие коммерческие имеют такие показатели (а подавляющее большинство и не имеет). Вы могли двигаться в сторону микросервисов, большинство же нет. :)

    Но нужно смотреть, что скрывается за этими запросами. :)
    Тут https://habrahabr.ru/post/262623/ тоже крутые цифры, а под капотом работа с первичным ключом одной таблицы.

    Не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности.
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    >Интересно было посмотреть, каких размеров ваши проекты

    Вы сначала хотели код.
    Так вот, какие оптимизации возможны для медленного DOM я сказал, причем 2 раза.
    У Вас еще другие проблемы есть?

    >какой сложности UI

    1. Сложность UI не стоит связывать с тормозами DOM.
    2. Очень сложный.
    Каша на jquery местами. :)
    Рефакторить никто не спешит, рефакторинг проводится частично только при внесении изменений, но не не глобальный рефакторинг.
    Задумываются над редизайном (но мне старшие коллеги (уволившиеся еще до того, как я пришел :) ) говорят, что это уже давно :) ).

    В личном проекте каши нет, там и кода мало, и логика не сильно сложная.
    А также нету тормозов DOM (это очень редкие проекты их имеют, но мыши побежали топиться в озеро под сладкую музыку, что React.js (любой другой) решит все их проблемы).

    >и как вы боретесь со стейтом.

    1. Что это такое?
    2. Оно вряд ли связано с тормозами DOM? :)
  • Javascript-фреймворки: должен остаться только один
    0
    Поддались моде? :)
  • Какие перспективы у Node.js после воссоединения — мнения экспертов
    –6
    За что хабрабыдло заминусовало? :)
  • Микросервисы: пожалуйста, не нужно
    0
    >Нет. В целях обучения мы можем выделять эти сервисы искуственно.

    Обучение без необходимости — это дерьмо. Человек ни хрена не поймет.
    Знания получил, думать не научился. :)
    Прежде всего нужно учить думать.

    >Разработчик без личных проектов — тоже самое, что адвокат без судебной практики.

    Совсем не то. И это сплошь и рядом.

    >У меня например не разбилось, что я делаю не так?

    Может это Вам лишь так кажется? :)

    >Проектирование это и не задача фреймворков.

    Уже нет? Не они задают архитектуру? :)

    >Первый раз мы решаем квадратное уравнение до реальной необходимости это сделать

    Сравнение некорректное.
    Решая квадратное уравнение мы решаем конкретную задачу: найти x.
    Здесь же абстрактное обучение в вакууме.

    Еще раз:
    Есть потребность — делаем, нету — не делаем.
    Не нужно искусственно что-то натягивать.

    >Да, в таком случае при возникновения этой самой необходимости ты делаешь миллионы ошибок, которые такой же программист УЖЕ преодалел, изучая и практикуясь.

    Программист, пишущий на фреймворках? :)
    Та они (в основном) и шагу ступить без него не могут.

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

    >Может всетаки дело не в необходимости а отсутствии у кого-то системного подхода к собственному обучению?

    1. Я не считаю себя супер-программистом.
    2. Необходимости в ООП не было, а я поддался моде. (Ну как вы советуете сейчас идти пилить микросервисы :) )
    Если Вы применяли с пониманием (хотя Вы говорите, что без :) ) и оно было необходимо (хотя в случае с микросервисами Вы говорите, что нет), то ок :)

    >ФУ, микросервисы мейнстрим, лучше буду дерьмо жрать с кучей инстансов монолитных приложений, зато НИКАК ФСЕ.

    Я такого не говорил.
    Я всегда говорю: Все нужно использовать по потребности и с умом! А не искать серебрянные пули.

    >Назовите хоть одну — уберем.

    Вы сами их упомянули:
    «Стандарты? Паттерны? Лучшие практики?»
    А также: ООП — тру (в последнее время: ФП — тру), фреймворки — тру, goto — зло.

    Ну не везде это нужно и оправдано. Тем более без понимания.

    >Обратного никто не утверждал.

    Как же. Вы же советуете играть с микросервисами без необходимости в них (а значит понимания нету).

    >Ну это вообще какой-то вброс дерьма на вентилятор. Стандарты? Паттерны? Лучшие практики? Что объединят три предыдущих вопроса? Это именно то «как делают другие» и разработчику на это не должно быть плевать.

    Разработчик, который не умеет думать, а использует готовую догматику, не понимает, что он делает.
    На поверхности получаем якобы и стандарты, и паттерны, и практики, только оно такое говнокодное, что капец. Ну или несвязная копипаста из разных мест :)
    Это обезьяна, а не разработчик.
    Серебрянной пули нету, а вы всем ее суете.

    >Для того, что бы у тебя появилось понимание, тебе нужно сначала их как минимум использовать :)

    Нет.
    Нужно читать стоящие книжки, смотреть примеры, делиться опытом.

    Иначе это будет варение в себе.
    На поверхности будут вроде и микросервисы, только сторонний наблюдатель подумает: ну нахера это тут?

    Если человек применяет подход без понимания, то он обезьяна.

    >В это болото можно и нужно лезть и из собственного интереса, но не на деньги работодателя

    Я согласен, что заниматься экспериментами на деньги работодателя не стоит.
    Я против этого и выступаю, когда крутые перцы говорят: а не переписать ли все на A фреймворк, а не поменять ли нам БД, а не добавить сюда еще эту приблуду.
    Хотя необходимости в этом нет, просто им скучно.
    Если же есть необходимость, то вряд ли ваш личный проект будет больше требовать разбиения на микросервисы (а они нужны не такому и большому количеству сайтов).
  • Оптимизация сайта. Диагнозы и курсы лечения
    0
    По верхам — это это: http://blog.kpitv.net/article/сайт-долго-загружается-15421/
    А тут достаточно подробно.

    Вряд ли выйдет в рамках одной статьи объять все моменты (хотя Вы и сами с этим согласны). :)
  • Оптимизация сайта. Диагнозы и курсы лечения
    0
    Разработчики СУБД? :)

    Не, не слышал.
    Сейчас же модно писать на фреймворке и не думать о СУБД. :)
    Абстрагироваться, так сказать. :)

  • Какие перспективы у Node.js после воссоединения — мнения экспертов
    +1
    Со стороны пользователя да.
    Но при этом мы можем иметь меньше запущенных процессов для обработки того же количества запросов.
    А также нету блокировок (если вдруг не наделали их :) )
  • Какие перспективы у Node.js после воссоединения — мнения экспертов
    –7
    Главному рисунку полтора года :)

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

    Повышались не то что требования.
    Просто некоторые задачи удобней решать на асинхронном Node.JS.

    >И лишь только после этого перейти к обработке следующего запроса.

    Вообще-то сервер может более одного запроса в один момент.
    У PHP несколько дочерних процессов, которые принимают запросы.

    >Тогда это дало бы возможность разрабатывать на одном и том же языке и серверную и клиентскую части сайта.

    В этом был главный плюс и причина возникновения Node.JS?

    >и запросов таких может одновременно быть пара тысяч

    Ну да, ну да.

    >Подобные соображения побудили любителей JS к созданию собственных серверных движков.

    Вы же сами говорите, что он на V8.

    >2 сентября был официально представлен

    Какого года?
    Напоминает: Украина получит безвиз в октябре (уже 10 лет получает :) ).

    >Основными проблемами, которые пришлось решать разработчикам в движке, стали производительность и масштабируемость.

    JS однопоточный вообще-то.
    То есть запускаем 100500 инстансов. Тут не нужно было думать о масштабируемости.

    >Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия.

    nginx тоже однопоточный.
    PHP тоже однопоточный (если не под многопоточным Апачем модулем).

    >в 2010-2015 годах разработчики добавили в хранилище кода более 190 000 модулей для Node.js

    Какая-то ерунда непонятная.
    Там модуля из 10 строк состоят? Модуль используется только автором?

    >Кроме того, она поддерживает 98% стандарта ECMAScript 6.

    Как считали проценты? :)

    >Однако растут не только номера версий Node.js. По данным Indeed.com, на рынке труда востребованность специалистов по Node.js продолжает расти.

    Это какая-то ерунда, а не рисунок.
    Node.JS — отдельная технология, а сравнивается с отдельными фреймворками других технологий. :)
    А также дальтоникам рисунок непонятен :)

    >1. Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?

    Блеать, та мне насрать на темпы развития.
    Или у него есть то, что мне нужно сейчас, или нет.

    Вы ж наклепали 200К модулей, самый быстрый язык, прям ракета.

    >Я не заметил какого-то резкого изменения спроса на Node.js разработчиков. Пожалуй, владение Node.js стало обязательным требованием для фронтенд-разработчиков в последнее время.

    Шта? Спроса нет, но требования обязательны?

    >Node.js — это всего лишь инструмент для выполнения JavaScript сценариев.

    Блеать, там не браузерный JS выполняется. Или у него интерес просто JS выполнять?
    PHP — это всего лишь инструмент выполнения PHP сценариев :)

    >Я считаю Node.js ждет большое будущее. Особенно среди фронтенд-разработчиков.

    Рилли? (Относится ко второму предложению).

    >Если чистый JavaScript, то очень быстро можно столкнуться с тем, что станет непонятно, что и как в вашей программе связано. Это следствие того, что JS динамический.

    Что за ерунда?
    PHP тоже динамичный.

    >В случае же использования TypeScript, например, у вас будет проверка типов на этапе компиляции

    А в рантайме придет не тот тип и здрасте :)

    >Тут от задачи зависит. Для микросервисов, на мой взгляд, – самое то.

    Микросервис — это проект?
    О боже, где вы берете таких экспертов.

    >Например, для написания небольших REST-сервисов.

    Вообще-то, любой HTTP-сервис — уже REST.

    >При большом количестве кода могут быть проблемы с прозрачностью логики работы приложения, но, как я уже говорил, это особенность JavaScript, которая вполне может быть решена с помощью Typescript

    Статическая типизация не повышает автоматом качество кода…

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

    В браузере? Будем запускать Node.js в браузере? Ооо.

    >Node.js откажется от V8 после стабилизации ES6, просто потому, что взаимодействие сервисов имеет несколько иную специфику нежели браузеров.

    Тупо бред.
    Можно отказаться от ES5 в пользу ES6 после стабилизации последнего
    Или от V8 после стабилизации ES6, потому что нам не нужен ES5.
    Но при чем тут одновременно V8, ES6 и браузеры?

    Вообще-то V8 — быстрая числодробилка. Как браузерный — он не сильно оптимальный.
    Но Node.JS и не использует его браузерность.
  • Микросервисы: пожалуйста, не нужно
    0
    Масштабировать само приложение не так сложно (в этом не такая большая нужда).
    И режут на микросервисы не только из-за масштабируемости, а и:
    а) чтобы не было блокировок, когда вместо синхронного выполнения тяжелой операции выполняютт ее в фоне.
    б) когда был монолит, но мы захотели предоставлять API доступ к нему: мобильное приложение, сторонние клиенты.

    А вот базу сложнее масштабировать.
    У кого-то есть данные, сколько занимают главные таблицы пользователей в ВК и ФБ? :)

    Основная поболь, кмк, невозможность выполнить запрос над данными более одного сервера.
    Хотя тут: https://habrastorage.org/getpro/habr/post_images/a07/038/4e5/a070384e516dd5466ee15fc314b1dc44.png
    https://habrahabr.ru/company/oleg-bunin/blog/309330/
    как бы есть решение.
    А также есть малоизвестный mysql-движок FEDERATED.

    Мне интересен такой вопрос:
    Как будет работать шардинг с группировками по данным из нескольких шард? :)
    Потому что обычные запросы можно выполнить и отдельно на каждом сервер.
    Работают ли межсерверные джойны (хотя это ад)?

    А также:
    Стоит ли делать шардинг по UUID (когда большинство запросов именно по UUID) и кто как его делает.
    Есть ли range ранжирование?
  • Микросервисы: пожалуйста, не нужно
    0
    Старению подвержены все… :)
    Старение не так страшно, когда можешь сам омолаживать по необходимости (самопись).
    В случае умирания фреймворка/CMS, выхода новой несовместимой версии поимеем боль :)

    Зоопарк сложнее поддерживать.
    Сотрудники слабо взаимозаменяемы.

    Выгоды от зоопарка больше у крупных компаний.
  • Микросервисы: пожалуйста, не нужно
    0
    Нужно заранее понимать, нужен ли сервис в данной ситуации или нет.
    Иначе это напоминает перебор индекса массива (больше/меньше, строгое/нестрогое неравенство), чтобы программа заработала. :)
    Понимания 0.

    Мало у кого есть личные проекты (хотя это плюс, а то имеем сапожников без сапог), а тем более требующие микросервисов.

    >Практический опыт ДО реальной необходимости

    Это типа умение дрочить? :)

    В реальности это все разобъется в пух и прах.
    В реальности придется думать в каждом конкретном случае, как резать монолит.
    Фреймворки за вас это не сделают.

    Кмк, вещи нужно использовать по мере необходимости и с пониманием.
    У меня тоже был дурной опыт. Например, с ООП. Молодой неокрепший ум (+без опыта коммерческой разработки еще) начитался, что это круто: наследование тебе, инкапсуляция.
    Ну и начал натягивать ООП (так был сделан, слава богу, только один подраздел).
    На поверхности был как бы ООП. Но это был ад. Я код вообще перестал понимать. :)
    Плюнул потом и переписал так, как понимаю.

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

    Но это не значит, что не нужно интересоваться новыми подходами. Нужно. Только применять их с пониманием.
  • Микросервисы: пожалуйста, не нужно
    0
    Хм.
    А как сервисам между собой общаться? :)

    Часто это сервер очередей или сервис, которы знает, как в кого ходить.

    Если же они будут безобразно ходить друг в дружку, то это только увеличение бардака, с которым мы якобы пытались бороться :)

    В общем, в неумелых руках любая технология будет порождать проблемы. :)
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    А смысл?

    Если Вы этого не поняли:
    «Есть куча оптимизаций. Самые простые:
    1. Не дергать 100500 раз $('selector').some_operationsN(), а сохранить $('selector') в переменную и работать с ней.
    2. Обновлять DOM не кусочками, а допустим сразу аккумулировать в переменную таблицу и вставить ее в DOM.»

    То я Вам ничем больше не помогу.
  • Фреймворк для простых проектов на jQuery
    +1
    Ага, это типа динамическая статическая страница.
    Шикардос.

    Из серии:
    Вровень выступать.
    7 параллельных взаимоперпендикулярных прямых.
  • Ради конкуренции с Apple и Amazon стриминг-сервис Spotify намерен купить SoundCloud
    0
    >В марте 2016 года у стриминг-сервиса появилась платная подписка.

    А до этого он был бесплатным?
    Как тогда он оплачивал авторские права?
    Пиратство?

    >У SoundCloud есть существенное преимущество перед другими сервисами – его поддерживает большое сообщество музыкантов.

    А, то есть некоторым пиратство прощается? :)
    Или там только неизвестные музыканты? Заглянул, известные.

    П.С.
    Я не поборник копирастии.