• Обзор ONYX BOOX Max 3: ридер с максимальным экраном
    +3
    Читаю книги, хабр, медиум и статьи в браузере с оникса только диагональю чуть меньше. По сути не ридер а полноценный планшет с инк экраном. Я доволен, читать получается больше, меньше устаешь даже просто за счет того, что все сайты и приложения в одном ч/б цвете.
  • Настройка среды для веб разработки в Windows на основе виртуальной машины VMware Player
    +1
    Я просто оставлю это здесь
    www.vagrantup.com
  • От Торонто до Томска: подведение итогов и планирование будущих семинаров по микроэлектронике в России
    +3
    В фиде сначала одна блондинка, заходишь в статью и на экране сразу другое фото из под ката, первая мысль — ничего себе там кормят на этом семинаре.
  • Как выбрать правильный лэптоп для программирования
    0
    Нет, это с ноута hp, сам не фанат пепеплачивать мака.
  • Как выбрать правильный лэптоп для программирования
    +1
    Вот если интересно скрин с 15-ки.
    http://take.ms/FvIBe
    Справа при желании можно еще базу воткнуть, у меня вместо нее плагин для быстрого перехода тыком в тач-экран.
  • Как выбрать правильный лэптоп для программирования
    0
    Я тоже сначала смотрел в сторону 17", многие годы работы за 21"+ мониторами вселяли уверенность, что все что мельче это неудобно в работе. Первым фактором который заставил задуматься была цена, очень мало машин с таким разрешением и нужными характеристиками, большая часть из них это игровые ноутбуки где я бы заплатил много денег совсем не за то. Самый подходящий по хар-кам сегмент — ультрабуки, все поголовно 13-15.

    Пошел в итоге смотреть 15-ки, провел целую операцию по отвлечению внимания продавцов и установкой шторма на ноутбук в торговом зале, впечатления оказались положительные. В итоге при переходе с 21" на 15" все, что поменялось в моей раскладке окон в шторме это переехало окно с базой данных с правой части экрана вниз. Без проблем помещается окно структуры слева с довольно большой вложенностью папок местами и в рабочей зоне при размере шрифта 15 пикселей помещаются 120 символов + еще остается запас.

    Ну и фактор веса, даже 20 минут пешком в день с двух килограммовой 15-кой и зарядкой на плече не всегда комфортно, не смотря не то, что тяжести меня не пугают. Таскать 17 я бы наверно совсем не хотел.
  • Как выбрать правильный лэптоп для программирования
    +2
    Статья малоинформативна, сам недавно перешел с работы на стационарном ПК на ноутбук и перед этим долго исследовал вопрос. Кто стоит перед таким выбором сейчас, вот мой список на что обратить внимание, если работаете в основном с веб:
    Разрешение
    1980х1020 — идеально для работы. 3840x2160 — только если берете макбук где весь софт адаптирован, под Win будете то и дело сталкиваться с тем, что в специфическом ПО, например в IDE, будут местами микроскопические элементы управления и тексты, вплоть до невозможности работы с ними. Также большее разрешение влияет на расход батареи.
    Процессор
    Для веб-разработки два ядра за глаза, главное на что смотрите, чтобы процессор поддерживал аппаратную виртуализацию для работы с виртуальными машинами.
    Память
    Если работаете с одной-двумя виртуалками одновременно 8 ГБ достаточно. Если больше — 16 гб.
    Видеокарта
    Интегрированной для работы и просмотра фильмов за глаза + меньше расход батареи.
    Клавиатура
    Тут у кого какие предпочтения, но я бы смотрел клавиатуру где есть цифровой блок и клавиши home/end/pgup/pgdown иначе будут иногда упражнения на растяжку ладони чтобы нажать комбинацию из трех клавиш в разных концах клавиатуры.
    Хранение данных
    Однозначно SSD, 256гб чисто для работы за глаза.
    Тач-скрин
    Очень удобно если — бываете на встречах где нужно провести демонстрацию, записываете или рисуете схемы, хотите использовать ноутбук и дома для чтения. В работе с IDE никаких преимуществ, поначалу пытался через тач делать некоторые вещи, например скроллинг, переход в определенное место в коде, но как-то эти попытки сами собой прекратились, в кодинге не помогает.

    По совокупности перечисленных выше факторов я свой выбор остановил на HP aq001ur, для меня это стало лучшим вложением денег в технику за последние годы. PHPStorm с кучей инспекций + одна-две виртуалки Vagrant без каких-либо проблем работают.
  • Как выбрать тот самый PHP-фреймворк. Сравнительное тестирование
    +1
    Количество чего? Запросов? От этого соотношение времени которое уходит на выполнение кода ядра фреймворка к времени выполнения остальнього кода не изменится. На тех масштабах, где играет роль 10 мс разницы времени генерации страницы между двумя фреймворками уже нет этих фреймворков, там остается голый php с выносом большей части инфраструктурного кода вообще на другие языки программирования. Вы не тем себе и другим голову забиваете. Интернет заполнен статьями подобными этой, где сравниваются хеллоу ворлды в вакууме, при этом единицы пишут полезные обзоры, где сравниваются реально значимые показатели фреймворков, такие как скорость разработки и простота поддержки, активность коммьюнити, база готовых наработок и интеграций и т.д.
  • Как выбрать тот самый PHP-фреймворк. Сравнительное тестирование
    +1
    В чем вообще смысл измерения производительности фреймворка, когда в реальном приложении 95% времени генерации страницы зависит от того что происходит на инфраструктурном уровне и уровне бизнес логики, на которые фреймворк вообще не влияет никак? Это все равно что сравнивать скорость двух автомобилей скатывая с горки голое шасси от них, а безопасность измерять роняя один двигатель на другой.

    Если фрейморк отдает голый хеллоу ворлд на десять миллисекунд дольше и загружает при этом на сотню файлов больше, говорит не о том, что он хуже, как раз наоборот он может оказаться лучше. предоставляя больше качественных абстракций для работы с низкоуровневыми вещами и готовых инструментов. Поэтому я бы все графики перевернул вверх ногами, тогда все фреймворки (кроме phalcon, его в силу реализации вообще неуместно сравнивать с остальными) окажутся как раз на своих местах — CI со второго места провалится в зад, где ему самое место в 2017 году.
  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0
    По мэпперам так и не понял, зачем вы выбрали такое решение, свалив в один класс и мэппинг и сохранение в базу. Это как минимум нарушает SRP и класс очень сильно раздуется если ему придется сохранять какой-то сложный агрегат со множеством внутренних связей, ValueObjects хранящихся по разным таблицам и т.д.

    Второй момент, зачем передавать обьект по ссылке вот так? У вас же судя по тайп-хинтингу явно не php4.
    function delete(\foci\model\Entity &$entity)
    


    А за статью спасибо, чужой велосипед всегда интересно посмотреть, когда это не просто копирование уже существующего решения а что-то оригинальное.
  • Построение модульной архитектуры приложения на Forwarding-декораторах (авторский перевод)
    0
    У меня один вопрос напрашивается, а как на это все тесты писать?
  • «Runn Me!» — говорит нам очередной фреймворк* на PHP. А слышится «Throw Me!». Часть 2
    +6
    Насколько у вас большой опыт командной разработки? Не со своими падаванами, где ваш подход априори не будет подвергаться сомнению, а с вашего или выше уровня разработчиками? Я просто с трудом представляю работу в команде над чем-то серьезным, если даже один член команды будет пользоваться не общепринятыми знакомыми всем практиками а своей поваренной книгой заклинаний.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    0
    Не беспокойтесь о репутации PHP.

    Я в данном случае беспокоюсь о себе и своем психическом здоровье через несколько лет, когда начну сталкиваться с кадрами взрощенными на фоне повышенного в данный момент интереса к профессии. Не хочу опять флешбеков из начала 2000-х.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    0
    Навыки ООП тут от клиента и не требуются, начейнить вызовов методов конфигуратора даже проще, чем с мануалом наперевес городить многомерный массив, который развалится как карточный домик при любой ошибке во вложенности. Как плюс — вы дадите своей целевой аудитории верное направление для развития, когда они захотят сделать что-то нестадартное и начнут разбирать как там все устроено. А так вы их сразу загоняете в яму, а потом удивляемся, почему у PHP такая репутация.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    0
    Мне понятна идея и цели которые вы преследовали, но непонятна реализация. Не понятно, почему явно более выигрышному в такой задаче обьектному подходу вы предпочли процедурный, причем в его наименее удобном воплощении, тем более, что с ооп у вас судя по всему все в порядке. Было бы все то же самое на обьектах, завязано на интерфейсы и декларативно собиралось через обьект-конфигуратор с fluent interface как бы все красиво и удобно было.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    0
    Обратите внимание, что на вашей диаграмме названия ролей это названия файлов которые вы инклюдите а не каких-то обособленных структур в коде, вроде классов или функций. Включение процедурного кода через include контекст не меняет и ответственность не делегирует, все что у вас там внутри происходит все равно тесно связано в один неделимый клубок. Невозможно изменить что-то в одной части системы не повредив другую — зависимость полная, причем зависимость на названия ключей массивов обьявленных в каком-то там из файлов. У вас по сути процедурный Page Controller распиханный на несколько файлов чтобы хоть как-то побороть копипасту, вот и вся архитектура.

    А за владение UML позвольте выразить свое почтение.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    +3
    А вы сможете изобразить архитектуру вашего проекта в виде диаграммы? Хотя бы flow обработки request-response? Мне кажется на диаграмме будет один блок примерно похожий на это:
    image
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    0
    Вы сильно зависите от IDE )) Ну это ваше право, конечно.

    Да, это видимо тоже зависимость, надо бы вспомнить лихую молодость и попрограммировать в блокноте.

    Вы понимаете что тут речь идет о прототипировании, а не о полноценной разработке? )

    Только проблема в том, что прототип потом придется полностью выкинуть, т.к. полноценная разработка на его основе невозможна. Я бы такое не купил.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    +1
    Зачем вам исходники, есть официальная документация, ее и нужно выкурить в первую очередь.

    Затем, что нажать в IDE на какой-то класс фреймворка и посмотреть код зачастую намного быстрее, чем открывать браузер, заходить на сайт, искать там нужный раздел документации по определнному классу и т.д. Хороший код не требует документации вообще.

    То есть чем больше зависимостей, тем лучше?

    Чем больше задач можно решить быстрее и надежнее использовав уже готовый, протестированный продукт — тем выгоднее и эффективнее разработка. Если мы конечно не рассматриваем случаи когда главный мотиватор это «потому что я могу». При грамотном подходе и зависимости на интерфейсы вы фактически даже не будете зависеть от этих сторонних библиотек. Сломалось что-то — заменили своей реализацией или встроили другую библиотеку через адаптер — нет проблем.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    0
    Вот честно, даже с Yii сколько работал уже, один хрен постоянно приходится лезть в исходники, чтобы поменять что-то в конфигурациях или виджетах. Это далеко не настолько ценная информация, чтобы тратить на нее драгоценную память.

    «Очень низкий порог входа» — только кажется. Фреймворк не интуитивный совершенно, самодокументация кода исходников — нулевая.

    «Очень прост в установке» — не проще чем composer require.

    «Отсутствие зависимостей» — а в чем тут собственно преимущество? Даже когда вы пишете на голом PHP, под ним более низкоуровневых зависимостей столько, что пытаться что-то экономить не используя composer в 2017-м году выглядит глупо, вы все равно будете зависеть от сотен других программных продуктов. Это не более чем попытка оправдания велосипедостроения.
  • SimplePage: простой, декларативный фреймворк для быстрого прототипирования
    +2
    Такой Array Oriented Programming даже разработчкиам Yii в кошмарном сне не снился :)
    Работать с таким API, где нужно постоянно вспоминать нужные названия ключей массивов — жуткая боль.
    Не понимаю, что мешает весь тот же функционал оформить в виде простых обьектов — и копипаста снизится и хотя бы какой-то толк появится от подсказок IDE. Тот же декларативный подход в сборке страницы можно сохранить применив Fluent Interface.
  • Уточка говорит «кря-кря», коровка говорит «му-му», «Runn Me!» — говорит нам очередной фреймворк* на PHP. Часть 1
    +3
    Давайте дальше посмотрим, валидация…

    https://github.com/RunnMe/Validation/blob/master/src/Validation/Validators/IntValidator.php

    Зачем делать класс валидатор с состоянием, вынуждая создавать новый экземпляр на каждую валидацию?

    Почти все валидаторы можно выкинуть включив одну директиву strict types, которую я к своему удивлению не увидел ни в одном файле вашего фреймворка, заточенного строго под PHP 7.0+ и с таймпхинтингом повсюду.

    Правда очень странная ситуация, у вас есть большой опыт, преподаете, я хотел найти в коде что-то реально ценное, но вижу только сборник антипаттернов и непонятные тяжеловесные обертки над нативными возможностями языка, не добавляющие сверху ничего нового кроме дыр и хардкоженного подавления ошибок тут и там. От чего вы пытаетесь абстрагироваться таким образом? От самого PHP?
  • Уточка говорит «кря-кря», коровка говорит «му-му», «Runn Me!» — говорит нам очередной фреймворк* на PHP. Часть 1
    +3
    Класс сериализации… вы преподаете на этих примерах? Пожалуйста, скажите, что нет.

    public function decode(string $data)
        {
            try {
                return eval('return ' . $data . ';');
            } catch (\ParseError $e) {
                throw new DecodeException($e->getMessage(), $e->getCode(), $e);
            }
        }
    
  • Уточка говорит «кря-кря», коровка говорит «му-му», «Runn Me!» — говорит нам очередной фреймворк* на PHP. Часть 1
    +4
    Посмотрел что у вас там дальше будет по циклу — веселье только начинается! Вот такая цепочка наследования…
    SimpleValue implements \JsonSerializable
    SimpleValueObject extends SimpleValue implements ValueObjectInterface
    class IntValue extends SimpleValueObject
    


    чтобы реализовать Value Object который хранит одно число?

    Я боюсь представить, сколько километров длинной будет цепочка наследования, когда дело дойдет до чего-то реально сложного.
  • Уточка говорит «кря-кря», коровка говорит «му-му», «Runn Me!» — говорит нам очередной фреймворк* на PHP. Часть 1
    +11
    С таким уровнем магии более подходящим названием для фрейморка будет «Гарри Поттер». Вжух! И мы сделали из обьектов массив, теперь туда можно сваливать как в помойку любое количество данных создавая новые под-помойки на лету! Но через два часа программирования такими «обьектами» они превращаются в ружье и отстреливают фокуснику обе ноги.
  • Yii2-advanced: Гибкая настройка Yii2 RBAC (роли, разрешения, правила)
    +2
    supper admin — администратор ужина? У вас там кулинарный портал какой-то?)
  • Работа из дома — один из главных бонусов, который требуют программисты
    +1
    Два года работаю удаленно — после полутора лет где-то недостатки стали перевешивать преимущества. Очень не хватает живого общения с коллегами, стали падать спортивные показатели из-за отсутствия еженевной активной мобильности (хотя бы та же поездка на работу), в итоге планирую арендовать место в коворкинге, круг замкнулся.
  • Как работают ИТ-специалисты. Федор Быков, директор по исследованиям и разработке в компании PROMT
    0
    Волшебный гусь передает Федору привет
    image
  • Чередование выборки в MySQL
    0
    Такие запросы база не может кешировать в принципе, тут и rand() и подзапросы, результат-то каждый раз разный.
    https://dev.mysql.com/doc/refman/5.7/en/query-cache-operation.html
  • Гантель как орудие ума
    +2
    Идея на миллион — IoT штанга, которая сама вслух считает твои повторы, повышая громкость и жесткость лексикона, если ты замедляешься. На последних повторах, если ты совсем застрял, может начать выдавать мотивационные реплики — давай жми дрищ, жим *** и т.д. Мне иногда кажется, что я плачу тренеру только ради этой незаменимой помощи.
  • Выборка случайной записи из таблицы с 700*10^6 строк
    +2
    Как вариант — готовить пул рандомных логинов заранее, резервируя их в нужном количестве (например 100 штук) в хранилище откуда их можно очень быстро достать, а саму генерацию пула вынести в отдельную задачу, за рамки запроса посетителя, которому требуется логин. Тогда время требуемое на генерацию рандомного логина уже не будет влиять на работу приложения которому эти логины нужны. Стратегий обновления такого пула можно придумать массу как и фоллбеков если вдруг всплеск нагрузки и пул исчерпан.
  • О том, как мы начинали разрабатывать собственную систему управления проектами и что из этого получилось
    0
    Посмотрел код, видно, что не бездумно делалось, но есть одна проблема. Из-за того что вы так долго делали в одиночку этот проект в полной изоляции, он очень сильно оброс понятными только вам одному конструкциями, конвенциями именования и т.д. Вы буквально стали незаменимым сотрудником. Хорошо это или плохо — смотря с чьей позиции смотреть. Я бы на вашем месте, если вы не планируете конечно там проработать до пенсии, начал думать о том, как это в случае чего передавать кому-то другому. Начал бы потихоньку переписывать на каком-то популярном фреймворке, ознакомился бы с актуальными стандартами, тесты, документация. Если убрать из вашего кода все велосипеды и использовать готовое, обьем уже не будет так пугать. Иначе в один прекрасный день компания может столкнуться с ситуацией, которая обойдется ей гораздо дороже, чем то первоначальное предложение с шестизначной суммой.
  • Немного о приватности реальных Git-репозиториев
    +1
    Лучше всетаки бороться с первопричиной и выносить файлы гита за пределы публичной папки веб-сервера, так гораздо меньше шансов забыть про что-то и допустить ошибку, чем при попытках закрывать доступ на них по отдельности. Паролям, сертификатам и любым другим аутентификационным данным, ровно как и бекапам баз данных содержащим такие данные под версионным контролем делать нечего.
  • Куда деваются программисты после 40
    +68
    Что-то зачастили с такими статьями на хабре, настолько, что мне аж в 30 уже страшно стало.
  • Развертка среды разработки Symfony под Windows
    +2
    Была та же проблема, на проект за два года привлекалось в общей сложности с десяток человек на временные работы по фронту, начинал так же с инструкции как поднять веб-сервер и php под windows, но что бы я не делал, у следующего всегда находилась какая-то уникальная ошибка на гугление и добавление в инструкцию которой тратилось время. После третьего или четвертого человека мне надоело бодаться с Win и потратив два вечера на настройку окружения под vagrant я забыл об этой проблеме навсегда. Две команды — и окружение готово, и никаких тебе хост-ос-специфичных проблем у каждого, какой бы балаган у него в винде не творился, окружение от этого изолировано. Как приятный бонус — vagrant share, можно смотреть что у него там происходит моментально если какой-то вопрос, без скриншотов, коммитов и т.д.
  • Вопрос с собеседования тим-лида: что делать, если деньги на проект получены и истрачены, а проект не готов
    +4
    Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново.


    В такой ситуации мне кажется виноваты все. Архитектор в том, что очевидно скрывал до самого последнего, что 20% нельзя будет реализовать на текущей архитектуре — первые признаки должны были появиться намного раньше, чем практически под сдачу проекта. Техлид виноват в том, что не увидел эту проблему сам и узнает о ней под сдачу проекта от архитектора — у техлида не хватает технической компетенции для самостоятельного анализа. Разработчики — в том, что сделали настолько связанную систему, что при добавлении 20% нового функционала ее приходится переписывать полностью. Отстранять в первую очередь тут надо тех-лида.
  • Уголовный кодекс разработчика
    +1
    Так можно делать если программа небольшая и вы можете держать в голове, что делает каждая ее часть. Если масштабы большие и разработчиков много, нужно уже работать по какому-то четко определенному регламенту, чтобы не изучая в деталях чужой код, можно было с ним работать. В вашем примере только 0.01% проверок нужна информация из базы, значит это неочевидное поведение для проверки — лезть в базу, и добавив в проверочный метод запрос в базу, наличие которого можно определить только изучив его код — его поведение уже не будет очевидо для остальных, кто-то засунет такую проверку внутрь цикла и начнутся проблемы описанные выше.
  • Уголовный кодекс разработчика
    +1
    Мне кажется этот пример не совсем удачный. Вы разбили семантически сильно связанную информацию обьем которой был и так невелик, естественно восприятие только уходшилось. Изначально же речь шла, с ваших же слов, о портянках по 2000 строк, которые и к данным напрямую обращаются, и стратегию их обработки содержат, и мэппинг в обьекты плюс какие-то инфраструктурные операции типа логирования:

    Для начала нужно проверить параметры, потом установить соединение, сформировать запрос, получить ответ, распарсить ответ, сопоставить сущности, выполнить кучу разных трансформов, записать данные, запротоколировать. Если вытянуть всё в одну колбасу, получается, например, 5 тыс. кода. Выносим повторяющиеся куски, получаем 2 тыс. строк основного метода...


    У вас есть пример такой портянки, в которой как вы считаете легко разобраться? Давайте на основе более-менее приближенных к реальности примерах вести дискуссию.
  • Уголовный кодекс разработчика
    0
    Если ваш монолит предназначен быстро решить какую-то задачу и отправиться в корзину или гаранитрованно не требует дальнейшей поддержки (что точно не относится к вашему примеру, который явно является частью бизнес логики, код которой обязан всегда быть готовым к быстрым и контролируемым изменениям) — естественно самым разумным решением будет набросать процедурную портянку, спрятать ее за фасадом и задача будет выполнена не создав технического долга. Здесь весь вопрос в дальнейшей поддержке. Нужно ли будет вернуться к этому коду через месяц, год, другому человеку возможно — если да, тогда в любом случае придется либо сразу делать нормально, либо делать рано или поздно рефакторинг, когда позволит время.

    Про флажок в базе данных не совсем понял.
    Предположим, в базу добавили флажок «Запретить отгрузку». Соответственно, если он для ItemID выставлен, то выполнение пускается по «обломной» ветке. Для добычи значения флажка уже есть метод GetStoppedFlagForItemID(), и вызов этого метода мы, не подумав, вписываем в условие. Здравствуй, тормоз.

    С чего должны возникнуть тормоза? Метод GetStoppedFlagForItemID() лезет в базу чтобы считать одно единственное свойство? Почему оно не считывается и не помещается в обьект Item к которому имеет отношение, когда он создается? А потом просто Item->isStopped()?
  • Уголовный кодекс разработчика
    +3
    В приведенном вами примере, добавив еще одну проверку в метод, который уже что-то проверяет другое и лезет за этим в базу, вы добавили ему неочевидный побочный эффект. Почему метод проверки сам лезет в базу? Он должен получить все нужные ему для проверки данные на входе — тогда и обращение в базу уйдет туда, где находятся все остальные обращения в базу, и станет очевидно, что нужен массив данных для выполнения всех проверок, который можно забрать одним запросом.