• Программисты не могут написать алгоритмы без помощи: ещё раз про интервью
    0
    Кто-то пишет калькуляторы, а кто-то — компиляторы.


    Классная фраза, я бы взял как заголовок даже.
  • Программисты не могут написать алгоритмы без помощи: ещё раз про интервью
    0
    Кстати, почти год назад был похожий срач (цикличность истории?),
    и я писал похожий по смыслу комментария пост
    https://habrahabr.ru/post/279651/
  • Программисты не могут написать алгоритмы без помощи: ещё раз про интервью
    +2
    Вся соль в детализации требований, кто такой этот «программист».

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

    Вот на примере профессии «водитель».
    1. Согласно ПДД
    Водитель — лицо, управляющее каким-либо транс­портным средством, погонщик, ведущий по дороге вьючных, верховых животных или стадо.


    2. В бытовом понимании — водитель легковой или грузовой машины.

    3. А еще есть водитель спортивного автомобиля.

    Три этих трактовки под одним словом. И если пытаться требования к водителю спортивной машины предъявить рядовому водителю — это будет нелепо.

    Так с чего же мы спорим о том, нужны алгоритмы или нет, или там знание определенных структур данных?

    Точно так же
    1. Если человек будет писать простые сайты на CMS — нафига ему алгоритмы? Гораздо важнее, чтобы он владел стэком front-endа, который сегодня переживает очередной бурный виток развития. Ибо за 1 день реакт или там ангулар не выучишь.

    2. Если человек будет заниматься поддержкой и развитием, например, криптографического софта — его базовые алгоритмы, конечно, спросят. Но гораздо больше потенциальных работодателей будет интересовать знание матаппарата из соответствующей области (малая теорема Ферма какая-нибудь, гипотезу Танияма-Шимуры могут спросить ради интереса, или математику асимметричных алгоритмов шифрования типа RSA)

    3. Если человека будут брать на Highload — скорее всего, спросят про архитектурный опыт. Про понимание, какие технологии он пробовал в боевых проектах, знает ли их слабые места (Redis, который забит весь, при падении не взлетит при перезагрузке сервера; какие-нибудь там распределенные файловые системы, тюнинг Postgres, или банальность, что нельзя кэш-файлы класть в одну папку — при огромном числе на определенных файловых системах читать оттуда будет очень долго).

    4. Если человека будут брать на разработку SQL — спросят про индексы, про какие-то особенности работы оптимизаторов запросов, еще что-нибудь.

    Ну а в конторы типа Гугла, Фейсбука и тд берут людей, которые имеют хорошее базовое фундаментальное образование — Computer Science + матан. Потому что да, там могут бросить человека и пилить фрэнд-фид в фейсбуке, и систему распознавания лиц на фотках, и даже вообще свою файловую систему или там транслятор PHP в плюсы / вариант виртуальной машины, чтобы не закупать 100500 новых серверов под растущий трафик.

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

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

    tl;dr Конечным для компании является то, может ли человек решать задачи, которые будут перед ним вставать, хватит ли у него таланта и опыта. Отсеивают либо по стандартным параметрам (если освоил CS / матан => пойдет), либо по достижениям (успешные проекты на Гитхабе, или взлетевшие стартапы).
    А вы, как кандидат, можете честно прикинуть, в чем вы сильны (или вас прет и вы можете стать сильны). И не пытаться втиснуться в прокрустово ложе чужих идеалов, а выбрать ваш путь.

    Успехов вам в нашем нелегком деле. Ведь сегодня в мире — наше время.
  • Upwork меняет сумму комиссии
    +1
    насчет рейта значительно выше $30 — если не секрет, это Java?
  • Алгоритмы — это лишь одна из переменных в уравнении
    0
    Все норм.
    А вообще то же умение дебажить — оно пипец как сложно.
    Просто чем отличается мышление теоретика vs практика (если до предела упростить)?
    Я строю алгоритм в голове/на бумаге, рассчитываю что он будет офигенно работать,
    и запускаю… получаю какие-то баги. Работает не так, как задумано.
    И если ПИПЕЦ УВЕРЕН что все правильно прикинул, сколько там памяти будет жрать и тд,
    то ошибку не найдешь.
    А если в голове имеешь опыт построения гипотез и их проверки (последовательно прикидывая возможные точки отказа),
    то отладишь гораздо быстрее.
    Тут стоит добавить, что есть типа еще BDD/TDD — в идеале и дебажить не нужно, сразу все работает и потом менять проще (сразу видишь по тестам, что поломал),
    но в целом ряде областей веб-программирования, highload систем и тд многие вещи тестами
    лишь имитируются (иногда через такую жопу, что страшно), либо вообще не воссоздаются в принципе.
    В общем, чем больше знаешь и умеешь и в целом мозги круче — тем лучше из тебя программист
  • Алгоритмы — это лишь одна из переменных в уравнении
    0
    У вас открывается веб-страница, отрабатывают аякс-запросы, уходящие на поддомены.
    Часть скриптов грузится с других поддоменов.
    Удивительным образом один из поддоменов смотрит на сервак с другой версией кода,
    чем тот, который вы тестируете (про дальнейшую цепочку распределения через балансировщики я не пишу).
    Допереть, почему код в ответ на аякс запрос, возвращает не то, что нужно, хотя вроде бы работает,
    могут далеко не все. Хотя когда знаешь ответ — это очевидно.
    Кейс из жизни, если что.
    Ну а про неверно прописанные NS-записи и глюки из-за этого думаю, у каждого полно историй из опыта.
  • Алгоритмы — это лишь одна из переменных в уравнении
    +5
    • Как отличить музыканта от программиста?
    • Покажите им C#. Музыкант прочитает "до диез", а программист "си шарп"
  • Алгоритмы — это лишь одна из переменных в уравнении
    0
    Да, есть такое дело.

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

    Как пример, вспоминаю ООП и паттерны. Первая практика, красивый код, старался — вылизывал. И тут жестокие требования бизнеса вынудили раз переписать, два, три — и совсем по-другому начинаешь смотреть на красивости из классов-классов и более любовно на всякие DRY, KISS, YAGNI, unix way. Потом и как с SOLID готовить понимаешь, и прочие другие вещи.

    То есть существуют разные способы сделать архитектуру внутри кода, спроектировать БД, выбрать стэк технологий и так далее. И нередко теоретически правильный и красивый может быть не нужен, а какой нужен, и когда нужно добавить правильности, а когда начисто делать сразу хорошо и идеально — дается только с опытом.
  • Алгоритмы — это лишь одна из переменных в уравнении
    +1
    Согласен.

    Я, кстати, за хорошую теоретическую базу, но без фанатизма. T-shaped, так они это называют.

    А то мне вот нравится теория игр (и теория вероятностей, куда без нее), всякие там равновесия Нэша, но никогда не скажу человеку, если он не владеет ею, что он — не программист. Разве только спрошу, какая вероятность того, что среди группы из двух футбольных команд и тренеров будут одинаковые дни рождения ))
  • Алгоритмы — это лишь одна из переменных в уравнении
    +2
    Кратко — не нужно противопоставлять теорию практике.
    База нужна? во многих сферах, где трудятся программисты, без нее не подняться выше определенного уровня

    Практический опыт и разный нужен? Да, без него в теории можно делать великие открытия и наука рулит. Но бизнесу нужна практика.

    Можно ли неуважать коллег, кто не владеет знаниями/навыками, которые вы считаете мастхэв для тру? Можно, у нас свободная страна. Но это неэффективно для группы в целом, кмк.
  • Алгоритмы — это лишь одна из переменных в уравнении
    0
    Спасибо за коммент.

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

    2.Безопасность отнюдь не заключается только в криптографии.

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

    3.Вот в случае с архитектурой, стэком технологий, базой данных и так далее есть такая злая штука — в реальности они работают сильно сложнее и нередко совсем не так, как мы моделируем в нашем воображении. Иначе бы никаких тестов производительности, всяких A/B проверок архитектуры на устойчивость к нагрузке и прочее не требовалось бы.

    Можно здесь вспомнить умную теорему про связь алгоритма, входных данных и предсказуемость результата; можно сказать про ненулевую вероятность ошибок в коде любого продукта, помноженную на сложность и объем современных систем и железа, что дает отличные от теории результаты.
    Но я просто отмечу, что помимо теоретических расчетов и выбора тех или иных решений по масштабированию или оптимизации, всегда вылезают какие-нибудь баги кэша ядра FreeBSD и распределенные файловые системы, настроенные как рассчитано, сбоят; внезапно барахлит какая-нибудь мелочь в рейде и Гластер не работает, как ожидалось, или же банально разрекламированный в новой версии языка-не-будем-называть сборщик мусора при превышении определенных пределов устраивает дикие тормоза.

    Поэтому знать и уметь основы Computer Science и… (допишите по вкусу) полезно и нужно. Но без практики и реальных боевых проектов, нагрузки, живого использования, развития и тд это сферический конь в вакууме (хотя и сферический конь в вакууме тоже может победить на скачках, как мы помним — только вот в каких)
  • Алгоритмы — это лишь одна из переменных в уравнении
    +8
    Вообще, я имел в виду немного другое. Посылов несколько:

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

    2. Также хотел подчеркнуть, что есть вещи, которыми мало озадачиваются те, кто бросается громкими фразами, по моей нерепрезентативной выборке. Про ту же архитектуру, про безопасность, про учет в разработке еще и как это будет поддерживаться админами хотя бы (аки учет всей стоимости владения автомобилем, а не его цены в салоне).
      И что эти вещи приходят лишь с практикой, но начинаются с признания, что это тоже нужно изучать. They say, the first step is to admit you have a problem.
  • Разные языки программирования и их области применения. Лекция в Яндексе
    +1
    Системы пишутся на сях.
    Очень много инфраструктурных вещей и технологий под веб — Postgres, интерпретаторы PHP, Python (Cpython) и тд пишутся на нем

    Крутой язык.
  • Как я мониторил Avito по SMS
    0
    Великий и могучий Perl. Когда-то он был основным языком веб-разработки, уступив затем место PHP. Ностальгия…
  • Возможности PostgreSQL, которых нет в MySQL, и наоборот
    0
    А есть ли полноценная многоверсионность в MySQL?
    Когда много пользователей читает/пишет в Мускуле, локи на уровне строки/таблицы раньше были задницей. То есть Мускул был __непригоден__ для нормальной нагрузке.

    А Постгрес вполне себе летал, и уже 8-9ка вполне себе сильно ближе по возможностям и уровню к Ораклу, а не игрушечному-плюшевому MySQL.

  • Как мы работали над редизайном Яндекс.Денег
    +2
    Из плюсов могу отметить только функционал — спасибо программистам и менеджерам проектов
    1. Офигенный штука с налогами

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

    3. СМС приходят лучше, чем у банков — не знаю как, но за это отдельный респект
  • Как мы работали над редизайном Яндекс.Денег
    +3
    1. № кошелька раньше был виден и было удобно копировать, сейчас неудобно

    2. История была простая и кондовая
    И с нормальным пейджингом.

    Сделали бесконечный лоадер.

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

    И да — если у вас общий отдел проектирования интерфейсов — передайте тому, кто выпилил Ctrl+лево/вправо из Яндекс.Поиска, отдельный антилайк/дизлайк от меня, как от пользователя.
  • Что может помочь менеджеру проектов в работе с программистами
    +1
    Диоген это был, по-моему
  • Руководство по выбору оборудования для подкастов от Дэна Бенжамина
    –9
    Цитирую ответ
    >Тут все понятно.
    А что, это не так? Это делается не в Китае? Вы поставите это оборудование в студии как хорошее? Аргументируйте ответы. Вы опозорились и теперь пытаетесь выйти из положения.

    > Небольшая ремарка: это перевод статьи основателя компании, которая никаким образом не связана с продажей оборудования
    А какая разница? Он просто слабо разбирается в предмете, а вы его тиражируете. Зачем? Вы с ним согласны? Если да — то вы некомпетентны. Если нет — то зачем статья здесь? Повторяю — это профанация.

    >Аналогично и тут.
    Что аналогично? Крыть вам нечем. Как вам не стыдно бездумно переводить всякую ерунду. Или вы отвечаете аргументированно, или соглашаетесь с тем, что о предмете не знаете ничего.
  • Руководство по выбору оборудования для подкастов от Дэна Бенжамина
    –7
    Вот развернутый ответ, который человек не может запостить, потому что у него нет акка на Хабре.

    >Я всем отвечаю одинаково: даже если у вашего подкаста хороший контент, но при этом плохое качество звука, его никто не будет слушать.
    Качество звука зависит много от чего и не дай вам бог подумать, что вы сможете спорить со студийной озвучкой с помощью покупки микрофона за 200 баксов. Тем более что в РФ он будет стоить 250-300. Все микрофоны, рекомендованные в статье — обыкновенная китайская дрянь такого уровня, где ± 200 баксов не решает ВООБЩЕ ничего. К тому же широкомембранная, что ласково и детально соберет все возможные шумы вашей комнаты и ее неблагозвучную реверберацию. Помимо микрофона нужен еще предусилитель и хороший АЦП. Можно по совету автора плюнуть на предусилок и взять USB, но к качеству и удобству пользования вас это вовсе, вовсе не приблизит. Тем более не приблизит оцифровка через входной канал встроенной звуковой карты, коей цена 10$. Автор об этом пункте скромно умолчал.

    >Sennheiser HD 202 II Professional Headphones
    Это СТАРТОВЫЙ уровень, ниже — только дно.

    >Итак, вы решили всерьез заняться подкастами. Например, появилась необходимость записать сразу нескольких человек в студии или же просто потребовался еще один микрофон. Пора переходить с USB-микрофона на стандартный XLR.
    Кому предназначена эта статья? Доселе складывалось впечатление, что для полностью начинающих, если не сказать для лохов. Тут людям, что первый раз в жизни покупают микрофон, предлагают настроить и записать многоканальную запись. Сомнительная затея, ну пускай.

    >Купите поп-фильтр
    А вот это обязательно, и это стартовый уровень. Это должно было быть в начале статьи красным шрифтом.

    >Heil PR-40
    Это все не самые популярные и не самые дешевые марки в РФ. Есть куда более эффективные по цене и по качеству, студийная классика, зарекомендовавшая себя годами, а не этот китайский новодел. Автора можно понять, ему это скорее всего вообще за копейки с ебея досталось, а у нас это все будет стоить хороших денег, которые можно и нужно потратить по-другому.

    > За приемлемую цену Mbox Mini и Mackie Blackjack, позволят подключить к ним два микрофона и соединиться
    А почему внешние звуковые карты? Внутренние того же качества стоят раза в полтора дешевле. Представленные модели, конечно, лучше чем канал ноутбука, но в общем — это китайское дно, ниже которого даже смотреть не стоит. Это старт. Их единственный плюс- это два канала и понятный интерфейс. Два канала для подкаста — это не первочередная задача, совсем.

    >После того, как вы вложились в хорошее оборудование, стоит задуматься о замене удлинителя на фильтр электропитания.

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

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

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

    >есть как 8-канальный, так и 16-канальный микшеры фирмы Mackie
    китайская хрень, рассчитанная на концертные выступления уровня «цыганская свадьба вези что не жалко».
    На концертах он удобен, на записи он только испортит звук. Дешевые предусилители и шум от схемы. Оно и понятно, этот микшер придуман не для этого.

    >Программное обеспечение
    а также использовать ПО с возможностью записи нескольких дорожек (например, Apple's Logic Pro X или Avid's Pro Tools).
    Угу, про тулз. Для того чтобы подкаст

    склеить и подсвести. Человек без опыта там будет копаться долго-долго чтобы звук услышать и разобраться куда кнопки жать. А цена у нее… Начнем с того, что сама DAW для таких задач мало что решает, подкаст свети можно даже в ущербнорожденной бесплатной audacity. Если уж тратить деньги на софт — надо брать хорошие шумодавы от Izotope и обработку голоса от Voxengo, тем самым кстати поддержите отечественных разработчиков.

    >Заключение
    Видно за версту почерк компании «для аудиофилов». Информации — ноль. Уровень компетенции — как у секретарши-стажера. Это полная профанация, пускай и перевод. Таким статьям не место на хабре!!!
  • Руководство по выбору оборудования для подкастов от Дэна Бенжамина
    –12
    Хорошие друзья просили передать, что статья УГ и не про жизнь вообще, а также КГ/АМ
  • Антиавральные решения
    0
    Мегадревняя статья )

    и да, отвлекает шум и лишняя информация — в том числе и коллеги
  • Почему иконки чаще мешают удобству, хотя и выглядят красиво
    +28
    Блин.

    Это охрененно. Очевидно, тут понятно, а наверху — херота какая-то.

    Недавно опять мучился со стиралкой. Выучил пару иконок, остальные не знаю.
    А так — умножьте 5-10 иконок на количество предметов, используемых в обиходе. Станет понятна проблема.

    Человек, если что, иконки помнит плохо. Может, японцы или китайцы их хорошо запоминают — образная память, иероглифы, вот это все.
    Конкретно по себе и по многочисленным знакомым и родным — скрипач не нужен. Либо надписи, либо иконки + надписи.
  • Почему нет простых решений о том, что лучше — купить серверов или оптимизировать код
    0
    Если упростить (что неверно), то я противопоставил «херак, херак и в продакшн» классическим «сделаем сразу хорошо и правильно» waterfall а-ля RUP.
    Ибо первое часто возникает, когда одни хотят запилить мегакрутую реализацию, а злой Тимлид или Скраммастер говорит какие-то слова про эволюционное проектирование, рефакторинг и заставляет выкладывать «неидеальный код». И отсюда и пошла эта тема.

    В то же время даже когда спутники и корабли в космос запускали, было много неизвестных. Возможно напишу про это статью, но вкратце суть такова.
    1. Делали поэтапно — опытный образец, потом Белки и Стрелки, только потом человек
    2. Было много неизвестных, которые определяли проектирование. Например, фраза из википедии
    В связи с этим в ОКБ разгорелись бурные споры и появилось два подхода к созданию спускаемой части станции. Первый подход предполагал толстый слой лунной пыли на поверхности и разработку средств посадки и передвижения по такому слою (например, пылевые катера на архимедовых винтах). Второй — что Луна была захвачена Землёй сравнительно недавно (несколько десятков тысяч лет назад, о чём говорили и легенды некоторых народов, в частности, догонов и о чём было известно С. П. Королёву), поэтому поверхность Луны, соответственно, твёрдая, на что и можно рассчитывать при посадке. Поскольку имела место явная нехватка подтверждённых научных данных, ни один подход не мог взять вверх, а разумно учесть оба по техническим причинам было невозможно. Известно, что в этих условиях С. П. Королёв принял волевое решение считать поверхность Луны твёрдой и рассчитывать станцию соответственно.


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

    Я на каждом шагу это встречаю.
  • Комментарий из публикации, перенесённой в черновики.
  • Комментарий из публикации, перенесённой в черновики.
  • Комментарий из публикации, перенесённой в черновики.
  • Комментарий из публикации, перенесённой в черновики.
  • 12 уроков из управления проектами и запуска стартапов
    0
    Да я фиг знает, их было много.

    Из всех книжек важно то, что вычленяешь.
    Например, я иногда читаю вот это blog.asmartbear.com
    Парень продал свой бизнес за сотни миллионов долларов, и он шарит в бизнесе. Конкретные вопросы освещает неплохо — я даже некоторые его статьи переводил.

    Понравилась мне книжка «Стартап без бюджета». Там вот именно по делу, и берешь — делаешь.

    Еще «Жесткий менеджмент» запомнился.

    Если будет время, попробую все подбить в какой-то список и выложить.
  • 12 уроков из управления проектами и запуска стартапов
    0
    Опыт был такой
    — софт на заказ (совсем мало)
    — свой софт, продажа типовых решений (совсем мало)
    — софт под MS Access (совсем мало)
    — небольшая студия, сайты (годик)
    — фриланс программером (пара лет)
    — фриласнс менеджером проектов (пара лет)

    В целом, делать свои проекты или же в рамках большой компании с ресурсами — самое оно по мне.
  • 12 уроков из управления проектами и запуска стартапов
    0
    Пожалуйста!
  • 12 уроков из управления проектами и запуска стартапов
    0
    Cогласен. Двумя руками подписываюсь
  • 12 уроков из управления проектами и запуска стартапов
    0
    Ссылки на провалившиеся проекты?
    Что касается работающих, на часть я могу вам дать ссылку в личку, где это допустимо.

  • 12 уроков из управления проектами и запуска стартапов
    0
    Как вы бы написали.

    Про партнерство — если эта статья наберет хотя бы 40-50 плюсов, напишу следующую статью, где затрону эту тему.
  • 12 уроков из управления проектами и запуска стартапов
    +1
    Приведите пару примеров, пожалуйста
  • 12 уроков из управления проектами и запуска стартапов
    0
    Каждому — свое. Все пути возможны. Если один проект, который приносит огромный доход, почему бы и нет.

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

    Масштабирование проектов, бизнеса — это совсем другая история. Я тут сам только учусь.
    И если развитие проектов как-то освоил, то с умением масштабирования бизнеса пока похвастать не могу :)

  • 12 уроков из управления проектами и запуска стартапов
    +1
    Что посоветуете почитать для улучшения?
  • 12 уроков из управления проектами и запуска стартапов
    0
    Когда как. Иногда за полгода запускается один большой. Иногда за год получается два десятка. Плюс, проекты разнятся по масштабу.
    Это, речь, конечно, об общей цифре, в том числе сделанного совместно с разными партнерами и коллегами, но обязательно с моим ключевым участием.

    Всякую совсем мелочь не считаю.
  • Контрактное программирование в PHP
    0
    Буду сволочью, но насколько быстро это работает,
    и как насчет использования TypeHintов для проверки, например, а также других менее хитрых возможностей и путей (в том числе, если так нужна своя типизация и централизация проверок — ее и создать, ООП это позволяет)?

    А так выглядит симпатично и интересно. Если еще и сделано не на уровне Reflection и прочей радости, а расширениями к ПХП и тд, чтобы быстро работало — то вообще гуд.
  • The Human Brain Project: Вы спрашивали – мы отвечаем
    0
    Ясно, step by step.

    Ну остается только пожелать успехов?