• Блокировка Telegram оставлена в силе по решению Мосгорсуда
    0
    Я вот никак не могу понять, а что мешает террористам использовать другие защищённые методы общения? Окей, про мессенджеры уже не говорю. Но вот что первое в голову пришло: заранее обменяться паролями, взять и создать файлик в keepass, внести туда свои данные и отправить всем своим друзьям любым существующим методом, хоть через ВК или mail.ru. Либо что мне мешает отправлять через тот же ВК заранее зашифрованные данные, например, RSA шифрованием? Администрация ВКонтакте тут уже ничем не поможет.
    Даже если Дуров прогнётся и сделает все так, как его просят сделать, и все сообщения будут в открытом виде на серверах, то что мешает другим сделать клиент, который повторяет текущую функциональность с е2е шифрованием? Просто сообщения будут передаваться через обычный чат в зашифрованном виде, а ключи будут только у пользователей
  • Умная колонка Echo записала частную беседу и отправила случайному контакту
    +3
    Наверное, потому что может, хочет, у них есть деньги и, скорее всего, большой дом с многочисленными комнатами в 2 (или более этажа), где одного такого девайса будет мало
  • Как мы на React 16 переезжали
    0

    Да, спасибо, уже переехали)

  • PHP может стать еще лучше
    0

    Любые функции можно импортировать через use, как и классы. Поэтому, это опять же не проблема.

  • PHP может стать еще лучше
    0

    Можно старые функции оставить, пометить как deprecated, а новое по-человечески запихивать в namespace'ы, а не в глобальную область видимости

  • PHP может стать еще лучше
    +7

    Было бы все просто, если было бы все просто. RFC писать без предварительной реализации и без тестов не имеет особого смысла (там так и сказано). Я бы с удовольствием поддержал проект кодом. Но сколько времени займет изучение языка C и исследование внутренностей проекта, прежде чем я смогу написать что-то толковое? С учетом полной рабочей занятости, на это могут уйти годы...

  • PHP может стать еще лучше
    0

    Спасибо, исправил

  • DevConf: из шаурмы в Symfony или миграция legacy
    0
    У нас такая же ситуация была. Но фронт контроллера не было, а было распихано по файлам. Проект был в настолько плохом состоянии, что написание тестов только навредило бы. Постелено внедрил в проект Yii2. Теперь от старого кода осталась только БД, которую я постепенно мигрирую на новый манер. Удивительно, но прям сложно это не было.
    Сейчас понимаю, что Yii2 — не самый подходящий для нашего проекта инструмент и хочу как-то переползти на Symfony. Только Yii2 не очень-то учит хорошим практикам программирования, и из-за нехватки опыта в свое я успел научиться плохому и жёстко привязать проект к фреймворку. И вот теперь я понимаю, что мигрировать с одного фреймворка на другой будет сложнее, чем этого хотелось
  • Собственные валидации полей для Rules в одном классе
    0

    Вы, к сожалению, правы на счет последнего. Обычный callable Yii2 в качестве валидатора не принимает (хотя очень хотелось бы). Достаточно посмотреть в код \yii\validators\Validator::createValidator


    Зато он принимает Closure! И тогда можно использовать одну из фич PHP7 Closure::fromCallable:


    \Closure::fromCallable([$this, 'validationMethod'])

    // Опять же, я не проверял. В теории, должно работать. Но идея с трейтами мне до сих пор не нравится.

  • Собственные валидации полей для Rules в одном классе
    0

    Не претендую на истинность высказываний, но Ваше решение очень плохо пахнет… Yii в качестве валидатора может принимать любой callable (ведь так?). Поэтому я бы предпочел либо сделать класс с набором статических методов-валидаторов [CustomValidators::class, 'phoneValidator'], либо создавать экземпляр класса и указывать метод [new CustomValidators(), 'phoneValidator'], либо можно вообще наполнить статическое свойство yii\validators\Validator::$builtInValidators конфигами часто используемых валидаторов и писать так: ['propertyToValidate', 'phone']. Но использовать для этого трейт и пихать все нужные и ненужные методы в класс… Почему-то мне кажется, это не самое лучшее решение…
    Я предпочитаю для часто используемых валидаторов использовать последний метод (для номеров телефонов, например), а в остальных случаях создавать новый класс и явно его указывать.
    // Все выше сказанное является абсолютным ИМХО

  • PHP ACL. Попытка сделать код безопаснее
    0
    Это все, конечно, здорово. Идея мне нравится. Но какой оверхед от этого, не замеряли? Или это все пока что на стадии концепта?
  • Чего боятся программисты?
    0

    Ну это само собой разумеющееся. У меня на компе работает локальная копия сайта. Благодаря докеру это не вызывает никаких проблем, сделать идентичное окружение, как на проде. Но согласитесь, взгляд со стороны и автоматические тесты дают значительный прирост качества проекту.
    Не знаю, как у других, но у меня глаз замыливается, я устаю и порой упускаю очень очевидные вещи и допускаю очень глупые ошибки.

  • Чего боятся программисты?
    0

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

  • Чего боятся программисты?
    0

    А на "бояться" как-то время не уходит. В проект только недавно внедрили автоматическое тестирование, а кодовая база уже немаленькая. Поэтому тестами покрываются сначала самые важные части системы, без которых функционирование сервиса будет совсем невозможным (Unit тестирование, тестирование API и п.р.); тестирование очень хрупких частей, изменение которых может повлечь за собой неадекватную реакцию на действия пользователей (в нашем случае — это тестирование правильного распределения прав доступа); а потом на то, что сломалось, стараюсь написать тест и поправить ошибку. Естественно, при внедрении новых функций стараюсь писать тесты, если это необходимо.

  • Чего боятся программисты?
    0

    Все бы ничего, но если ты один кодер/верстальщик/дизайнер/тестер на весь проект, то времени и сил тестить "побольше" как-то совсем нет.

  • Чего боятся программисты?
    +5

    Скажу про себя. Эти фобии больше зависят от проекта, чем от человека:
    Фобия выкатить в релиз. Каждый раз боюсь выкатывать новую версию кода в релиз. Особенно если правок произошло достаточно много с момента последнего деплоя. Лечится частыми и мелкими релизами, тестированием изменений другим человеком и автоматические тесты жизненно важных частей системы. Хотя, фобия часто остается. Особенно, когда ты единственный кодер и вся ответственность на тебе.
    Фобия что-то менять в коде. Обычно прослеживается в монолитных сложных спагетти системах. Тут естественно поможет TDD, что улучшит качество кода в разы, компонентный подход и нормальное наименование переменных/функций/классов/namespace'ов/п.р… Про комментарии не говорю, потому что хорошая архитектура и грамотно написанный код намного лучше любых комментариев.
    Страх брать сложные задачи. Не всегда это последствия лени. Пожалуй, это скорее последствия первых двух фобий, когда ты просто боишься сломать все, что уже сделано. Особенно, если можешь получить от этого втык. Лекарства все те же: тесты, хорошая архитектура и чистый код.
    Это то, с чем столкнулся я. Сказать честно, думал, что в статье речь пойдет о подобном. Но нет. Тут все намного глубже.
    Если говорить о подобных психологических моментах, то сейчас я боюсь работать с другими людьми. Всю свою карьеру работаю один удаленно. Ни разу не работал в команде. Если вдруг начальство решит взять еще одного человека, я даже не представляю, как я ему буду объяснять, что творится в моем коде.

  • Webpack 4 и code splitting
    +1
    Хочу поинтересоваться, а что не так с sass?
  • Webpack 4 и code splitting
    0
    Я с вами согласен. Но частично. Скажу за себя. Я выбрал свой любимый frontend стек для разработки — ReactJS, Redux, Bootstrap, SCSS и т.п. Конечно, хорошо знать все то разнообразие, которое предлагает современное сообщество. Но будучи обычным backend разработчиком я в эти дебри не лезу. Я не знаю, как готовить Angular, Backbone, не умею в Typescript и т.д. Читаю статьи либо общего характера, либо связанные с моими инструментами. И не испытываю того дикого дискомфорта, который ощущаете Вы. Но да, когда я только начал знакомиться с фронтендом, я был потерян и запутан.
    Что касательно всяких там вебпаков и бабелей. Эти инструменты слишком универсальны, чтобы быть простыми. Проектов много, они разные, у всех разные потребности. Да и без них пока никак. Браузеры только сейчас научились import, а есть ещё большой процент старых и мобильных браузеров, которые до сей поры про let и const не знают.
    Если говорить о разнообразии, то это же здорово! Вспомнить только про npm и yarn. Пока второй не появился, первый не особо стремился оптимизировать скорость загрузки пакетов. Конкуренция это всегда хорошо.
  • Звук в ReactJS
    0

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

  • Yii 2.0.14
    0

    Вы правы. Но так как это моя основная работа — веб разработка, то на железо не скуплюсь. Окупается почти сразу

  • Yii 2.0.14
    +2

    А если воспользоваться IDE PHPStorm, то можно провести поиск использования класса Object и везде поменять его на BaseObject.

  • CQRS. Факты и заблуждения
    +2
    Пишу на PHP. Использую что-то подобное cqrs, что упростило код, сделало его симпатичнее, проще в поддержании. Я не знаю, как на шарпе все реализовано, но у меня один маленький тоненький command bus и ещё один такой же query bus куда я кидаю команды и запросы. Они просто пробрасывают запрос/команду в нужный обработчик. Так я смогу в будущем переключить выполнение команд с основного потока в очередь. Единственное, что мне до сей поры очень плохо ясно, это куда во всей этой схеме пихать валидацию? Мне предлагали сделать что-то типо middleware, где я бы перехватывал команду и валидировал данные в ней. В итоге пришел к самому простому: команда с валидацией реализует интерфейс ValidatableInterface с методом validate и command bus выбрасывал бы исключение при ошибке. А что, если мне нужно проверить одни и те же данные в разных местах? Писать валидаторы для каждого свойства? Может быть есть какой-то толковый материал на эту тему? Можно англоязычный. Да и вообще не тему cqrs, но без es.

    Автору спасибо за статью. Собираю по крупицам информацию. Не задумывался, почему может быть плохо использовать query внутри command. Тут был поднят вопрос без ответа на него: что делать с автосгенерированными БД ID? Я полагаю, тут истинно верного решения нет?
  • Советы по стилю. Как написать читаемый React-код
    0

    Исторически так сложилось. Весь проект (стили) собирается из одного SCSS файла с подключаемыми в него другими SCSS файлами. В этой ситуации выбор не особо велик: либо все переписывать, либо оставить как есть. Решили идти путем наименьшего сопротивления и использовать BEM.

  • PHP-Дайджест № 124 (14 – 28 января 2018)
    +6
    В Yii2 есть такая штука, как GridView.
    Можете глязануть этот русскоязычный материал: nix-tips.ru/yii2-razbiraemsya-s-gridview.html
    Может очень много и позволит на скорую руку слепить красивую таблицу с фильтрами и сортировкой.
    Но предупрежу заранее — это НЕ библиотека, и Вам придется подключатьь целый фреймворк. Хотя в случае с Yii2, это не так уж сложно.
  • Советы по стилю. Как написать читаемый React-код
    0
    Может быть я что-то упустил, но в мобильном хабра-приложении «приведенного выше примера» я не вижу.

    Кстати о тестировании. Работаю совсем один над крупным проектом (бывает и такое). Тесты пишу не всегда, но иногда они (те, что есть) просто спасают. Бывает что-то отваливается или просто что-то забываю вернуть, это сразу отображается в результатах тестов. Особенно вдохновляют acceptance тесты, где можно посмотреть на живой браузер и скриншот с ошибкой.

    Ещё момент: некоторые плагины под eslint для ReactJS (по крайней мере тот, которым пользуюсь я) буквально заставляют добавлять displayName компонентам-функциям. С одной стороны это удобно при отладке. Но с другой стороны `export default () => Hi!` смотрится лаконичнее.

    Также использую подход с декораторами: некоторые компоненты являются обертками для других, используются как декораторы (`@something`) и в displayName указывается `DecoratorsName(ChildComponentName)`. Идея не нова: уже давно используется в react-redux и react-form. Я использую данный подход для bem классов. Можно использовать для темизации. Очень удобно.
  • Редактирование комментариев
    0

    Нет

  • PHP-Дайджест № 123 (1 – 14 января 2018)
    +1

    Плохо этот комментарий сказался на карме… Сначала думал промолчать. Надо было не передумывать.
    Авторам большое спасибо за найденный материал. Из этих дайджестов я на самом деле узнал очень много для себя. Особенно нравится раздел "Инструменты".


    Небольшое замечание от себя: Yandex DNS с семейным фильтром почему-то считает Ваш сайт сайтом для взрослых и не пускает:


    Сайт для возрослых

    Яндекс DNS


    Яндекс даже в поиске ничего не выдает:


    Пустой поиск


    Я отправил им свое несогласие через форму. Но от меня одного вряд ли что-то зависит

  • Изучаем команду wget на 12 примерах
    0
    Я тоже предпочитаю качать через консоль. GUI качалки либо слишком просты, либо чересчур загружены. Браузер часто недокачивает. А когда нужно скачать пачкой, намного проще упихать все ссылки в один файл и одной командой все получить.
  • Изучаем команду wget на 12 примерах
    0
    GitHub Pages? Допустим, документацию по ReactJS выкачать, чтобы почитать на досуге, пока куда-то едешь (проезда, автобусы междугородние).
  • PHP-Дайджест № 123 (1 – 14 января 2018)
    –14
    Судя по тому, насколько реже стали выходить джайзесты, и как уменьшается их содержимое можно сделать вывод: либо PHP достаточно зрел и всё, что можно написать про него, было уже давно написано, либо PHP понемногу умирает. Либо просто хайпа нет столько.
  • Первый взгляд на react-native
    +1
    Зато он невероятно удобен для pet проектов. У меня где-то с десяток небольших приложений, написанных за пару дней, для меня и моей семьи.
    Про серьёзные приложения ничего сказать не могу, так как это не мой род деятельности. Но мне, как веб разработчику, очень нравится подобная технология из-за знакомого мне JavaScript.
  • Первый взгляд на react-native
    0
    Хочу заметить, что React Native очень хорошо работает с async/await. И тем образом код становится очень аккуратным и легко читаемым. Правда, отловить забытый await порой бывает очень сложно. Вроде как даже перед такими функциями, как componentWillMount, можно ставить async
  • Топ-10 библиотек для React на GitHub
    0
    Ссылка на Ant Design ведёт на 404 Page Not Found
  • Как прочитать большой файл средствами PHP (не грохнув при этом сервак)
    0
    Люблю статьи, которые освещают темные участки документации. Темные в том смысле, что сам не полез бы разбираться, а в статьях упоминаний мало. Спасибо большое.
  • Что нового в WebStorm 2017.3
    0
    Бывает… попробуйте инвалидировать кеш и перезапустить IDE. Если не помогло, переподключите NodeJS в настройках. Иногда, после обновления Web и PHP Storm забывают про папку node_modules. Если и это не помогло, пишите issue. У меня эти проблемы решались именно так
  • Docker, как показатель зрелости
    0

    У нас даже таких объемов нет. Таблицы в среднем по 1000 строк. Помимо прочего, у меня 14.04 версия убунты. Новая версия (6.3.10) может не запуститься (пробовал как-то), а вот как раз старая (6.2.5), которые предназначены для моей версии, запускается. Но она не стабильна и в специфичных местах вылетает

  • Docker, как показатель зрелости
    +1

    Я использовал workbench какое-то время. Но мне он не нравится. Раньше частенько вылетал посреди работы.
    Вариант с "PHPStorm с встроенным в него DataGrip" мне нравится больше. И мне этого пока что достаточно.
    Про Wine я имел в виду, чтобы использовать HeidiSQL. По крайней мере готовый DEB пакет я не нашел.

  • Docker, как показатель зрелости
    0

    Но это мой аргумент) И это причина по которой я не исползую PMA в продакшене. Мне было интересно узнать, что скажут мне на это люди. В итоге, единственный адекватный аргумент против использования PMA был, что это "лишняя нагрузка на сервер". Остальные были в духе "он морально устарел используй XXX"

  • Docker, как показатель зрелости
    0

    Да сколько можно? Ранее пользовался local, в форуме мне намекнули, что не нужно, потому что это зарезервированный домен. Начал пользоваться dev. Да нет же, его тоже решили занять… Хорошо, что test, как оказалось, тоже зарезервированный, но для разработчиков.
    Спасибо больше за ссылку. Добавил пояснение в статью.

  • Docker, как показатель зрелости
    0

    Возможно, я попутал термины. Подумаю, что можно сделать, чтобы не переписывать всю статью.
    Основное преимущество Docker перед VB в первую очередь в том, что он не ест столько оперативки и не требует целой кучи ресурсов.
    У меня всего 8гб, на плечи которых лежит PHPstorm со всеми плюшками, Chrome с десятком плагинов, Webpack с запущенным на нем Hot reload и ещё несколько инструментов. Чтобы запустить и держать в рабочем состоянии VB рядом со всем этим добром, нужно ресурсов гораздо больше. В итоге, ОЗУ заканчивалась, процессы лезли в swap и насиловали мой HDD, после чего разработка становится невыносимой и приходилось от чего-то отказываться.
    VB запускает всю систему целиком со всеми ее процессами, которых не так уж и мало. В свою очередь Docker запускает только то, что мне нужно.
    Docker запускается намного быстрее. Подключать дополнительные компоненты удобно. Тестировать хорошо, так как можно быстро поднять новый, чистый контейнер. Selenium работает из коробки без всяких танцев с бубном.
    Для себя я нашел много преимуществ. Если их не находите Вы, это может говорить об одном — Вам он (Docker) просто не нужен.