Нееет.
Я сказал, что по данным WiFi чипа (там не только МАС, который можно подделать, и даже на хабре когда-то была статья по поводу однозначной идентификации WiFi чипов/модулей) можно легко получить данные по IMEI аппарата и, затем, его владельце. Не выходя из подвала КГБ.
В случае с ноутбуком — по модели ноутбука (и серийнике его винды, к примеру, если там винда, а это, чаще всего, так), но я в тот момент думал о портативных устройствах, т.к., обычно, именно с них идёт залив/слив контрафакта через публичные точки.
У всех производителей есть база, куда заносятся серийники всех модулей и блоков в каждом выпущенном аппарате. Официальная версия — для нужд гарантийного ремонта.
В общем, при наличии желания и ресурса, клубочек разматывается довольно быстро.
Чтоб исключить данный риск, ребята жгут ноутбуки/телефоны/флешки. Их цена не сравнима с ценой провала.
ПС. Мак в заминусованном посте, это макдоналдс. На всякий случай…
Зато у производителя мобильного устройства есть данные по МАС адресу установленного в ваш IMEI модуля.
Я в курсе, и так оно и написано. Я не уточнил по МАС, т.к. помимо него у беспроводных чипов есть ещё несколько параметров, которые можно считать дистанционно и которые оставляют следы.
Не забываем также, что сейчас большинство чипов идут совмещёнными — вифи + блюпуп + рфид и т.п. на одном кристалле.
Таким образом, нет ничего сложного узнать модель аппарата и, часто, владельца (если у вас не краденный в европе аппарат, к примеру).
В любом случае, если вас возьмут лично, живой изъятый аппарат будет доказательством ваших рассылок или чего вы там с него делали.
Подсовываешь кому? Одному из мальчиков Боготы, который купит ноут в одном из магазинов Боготы за налик?
Ноут в печке рвёт следы. Ты можешь отправить письмо из мака, даже с улицы, но твоё устройство будет идентифицировано хотя бы по данным WiFi чипа, через который пробьют IMEI и через него найдут тебя.
Телеграм изначально позиционировался именно как защищённое средство передачи информации. В пику злым ФСБешникам, оккупировавшим Вконтакт. На деле же (и иначе быть не могло) защищает он лишь на бытовом уровне.
Защиту коммерческой информации мы в году 2001-м делали архивируя винраром с шифрованием AES. Сегодня средств шифрования, в том числе с открытым исходным кодом, которые можно проверить и допилить под себя (добавить XOR, гы) достаточно. И передавай по мылу. Конкуренты не вскроют а от FBI мы, вроде как, и не защищаемся ;)
Засечённый самолёт отвечает открыто, равно как имеет опознавательные знаки на борту. Смысл шифровать? Или враг не откроет огонь, получив в ответ мусор вместо ответа?
Что до секретных приказов, их до сих пор развозят в портупеях, причём по обе стороны океана. Онлайн передача используется лишь в критических по времени ситуациях, когда приказ будет исполнен раньше, чем посылку расшифруют.
--Более того, само по себе использование общедоступных платформ (Android, iOS) уже делают в принципе несекьюрным против правительственных служб.
Да, именно.
Я живу в Колумбии и общаюсь, скажем так, с разными людьми. Я НИ РАЗУ не видел, чтоб любые данные передавались по любым каналам электронной связи. Либо личная встреча, либо посыльный.
Данные передают на флешках. Причём на разъём и контакты наносятся поперечные царапины — если флешку вставить в разъём хоть раз, кромки царапин сминаются и восстановить их нельзя. Минута над микроскопом позволяет понять, совали флеху или нет. Игольчатые и лепестковые контакты также оставляют след на позолоте контактов.
Раз наблюдал картину — менсахеро (пацан лет 15) привозит ноут на мотоцикле. Ноут новый, даже заводская винда ещё не развёрнута.
Разворачивают винду, регистрируют ящик на яху, пишут несколько писем. Ящик удаляют, ноут закрывают и… в печку. Чтоб даже следов мак-адреса сетевухи не осталось.
Это я к чему? Это я к тому, что средства вроде телеграма будут востребованы у Мани, пересылающей фото сиськофф Ване. И опасающейся, что супер-злодей похитит её фото. Но в серьёзном бизнесе, для защиты от FBR, ФСБ и прочих узурпаторов безудержной свободы, ни это, ни любое другое средство шифрования не будет востребовано.
Я использовал метод Байеса в своей дипломной работе «Динамические экспертные системы при оценке рисков в страховании». Основной конечно же были генетические алгоритмы в сочетании с методом Байеса.
В принципе их можно применять абсолютно везде (другой вопрос, насколько это целесообразно).
Вообще, есть три цели анализа данных: оценка параметров, прогнозирование данных и сравнение моделей. С помощью байесовских методов можно достичь все три цели.
Из практических примеров, можно назвать следующее, что приходит в голову.
Как писал MAGNUS8, на основе байесовских сетей можно строить системы принятия решений.
Еще одна практическая задача, которой занимаюсь я, состоит в обработке данных физического эксперимента. Есть данные с различных приборов. Причем одни приборы измеряют точно величину параметра, но у них большая неопределенность в координате измерения (то есть измеряют точно, но непонятно где), а другие измеряют в определенном месте, но неточно. С помощью байесовского анализа можно анализировать данные с разных приборов не изолированно, а вместе, за счет чего достигается эффект синергии, и неопределенность в результатах уменьшается.
Еще одна частая задачка в физике и астрономии состоит в следующем. У вас есть сильнозашумленные данные, в которых есть сигналы определенной формы. Но из-за шума вы не можете сказать, в какое время сигналы появлялись и какова их амплитуда. Байесовский анализ в этом поможет.
На основе байесовского анализа вы можете прогнозировать данные. Например, у вас есть исторический тренд какого-то параметра (например, стоимость акций, ВВП и пр.), и вы ходите узнать, с какой вероятностью в следующий момент времени произойдет скачок этого параметра на определенную величину (такой тип задач можно найти и в физике, и в, например, финансах и экономике).
Что касается книжек, то мне очень нравится книга John K. Kruschke «Doing Bayesian Data Analysis: A Tutorial with R and BUGS». Я думаю, это одна из лучших (если не лучшая) практических книг по Байесовскому анализу данных. Она блестяще написана, там приведено большое количество программ на R и после всех глав есть упражнения к этим программам, что позволяет почувствовать теорию на практике.
Еще есть замечательная книга D. Sivia «Data Analysis: A Bayesian Tutorial». Она ориентирована на практику, хотя там не рассматриваются вопросы реализации анализа на каком-либо языке.
И, наконец, Andrew Gelman et all. «Bayesian Data Analysis» — это замечательный учебник, хотя в большей степени теоретический.
Хоть и на английском, но мне понравилось как разъясняются Байесовские методы в книге Christopher M. Bishop «Pattern Recognition and Machine Learning» — хорошие примеры, много иллюстраций, простой, технический английский.
Сейчас времени не ахти как много, после диплома хочу тоже куда-нибудь это применить. Найти бы ещё простую тему =).
Сама ИС на методологии COSO Internal Controls основана. Контроли в основном на жестких правилах, но есть ряд задач, когда жестких критериев нарушения нет и нужно выбрать из «генеральной совокупности» бизнес-объектов наиболее подозрительные для последующей ручной проверки. Опыт и знание бизнес-процесса обычно позволяют указать 5-7 вычисляемых событий, которые сами по себе (по отдельности) ничего не значат и «жареными фактами», подтверждающими мошенничество, не являются, но повышают подозрительность. А дальше эти события в совокупности «голосуют» за или против гипотезы о фроде применительно к конкретному бизнес-объекту (экземпляру бизнес-процесса). Формула: Постериорный шанс фрода = (априорный шанс фрода) * LR (событие1) * LR(событие2) *...* LR(событиеN). События должны быть взаимно независимыми, чтобы тупое домножение на LR работало (иначе надо учитывать разные последовательности появления событий и, соответственно, условные шансы, что крайне существенно усложнит формулу).
МГУА глянул — очень сильная вещь, буду изучать, спасибо.
Практических применений у этих формул — несчетное множество. На вот этой самой формуле Байеса построена вся современная радиотехника. Например, алгоритмы слежения за сигналом — ничто иное, как алгоритмы расчета (в приведенных в статье обозначениях) p(\theta | Data). Где \theta — различные параметры сигнала, а Data — принятый сигнал.
В моем текущем проекте (ИС для выявления мошенничества на производственном предприятии) используется формула Байеса в разновидности алгоритма likelihood ratio test. Для определения вероятности фрода при наличии/отсутствии нескольких фактов, косвенно свидетельствующих в пользу гипотезы о возможности совершения фрода. Алгоритм самообучаем (с обратной связью), т.е. пересчитывает свои коэффициенты (условные вероятности) при фактическом подтверждении или неподтверждении фрода при проверке службой экономической безопасности.
Стоит, наверное, сказать, что подобные методы при проектировании алгоритмов требуют достаточно высокой математической культуры разработчика, т.к. малейшая ошибка в выводе и/или реализации вычислительных формул сведет на нет и дискредитирует весь метод. Вероятностные методы особенно этим грешат, поскольку мышление человека не приспособлено для работы с вероятностными категориями и, соответственно, отсутствует «наглядность» и понимание «физического смысла» промежуточных и итоговых вероятностных параметров. Такое понимание есть лишь для базовых понятий теории вероятностей, а дальше нужно лишь очень аккуратно комбинировать и выводить сложные вещи по законам теории вероятностей — здравый смысл для композитных объектов уже не поможет. С этим, в частности, связаны достаточно серьезные методологические баталии, проходящие на страницах современных книг по философии вероятности, а также большое количество софизмов, парадоксов и задачек-курьезов по этой теме.
Еще один нюанс, с которым пришлось столкнуться — к сожалению, практически все мало-мальски ПОЛЕЗНОЕ НА ПРАКТИКЕ на эту тему написано на английском языке. В русскоязычных источниках в-основном только общеизвестная теория с демонстрационными примерами лишь для самых примитивных случаев.
На самом деле, я даже несколько поразился «разумности» системы. В хорошем смысле. Так что, имхо сделано гораздо лучше, чем могло бы быть. Действительно, если бы он просто исправил на «cheesburger», это было бы слишком ожидаемо и скучно! Выглядит интеллектуально засчет того, что с точки зрения компьютерной системы — это абсолютно разные слова, а вот с точки зрения человека — очень близкие понятия. И такое поведение придало ей в определенном смысле человечности.
«Если я вам скажу “темно как у негра в …”, вы сразу поймете о каком месте чем идет речь, даже если я не закончу фразу. Так происходит потому что в натуральном языке вероятность появления слова сильно зависит от контекста. Байесовский же классификатор представляет документ как набор слов вероятности которых условно не зависят друг от друга.»
отлично расписано!!! )))
Так и сделал :). Разбил на два корпуса. Стандартная, вобщем, практика. names.txt — файлик создавался шафлом по списку женских и мужских имен.
А в чем результат завышен?
Ниже — код для тестирования.
def test(classifier, test_set):
hits = 0
for feats, label in test_set:
if label == classify(classifier, feats):
hits += 1
return hits/len(test_set)
def get_features(sample): return (
'll: %s' % sample[-1], # get last letter
'fl: %s' % sample[1], # get first letter
'sl: %s' % sample[0], # get second letter
)
if __name__ == '__main__':
samples = (line.decode('utf-8').split() for line in open('names.txt'))
features = [(get_features(feat), label) for feat, label in samples]
train_set, test_set = features[:-100], features[-100:]
classifier = train(train_set)
print 'Accuracy: ', test(classifier, test_set)
В экосистеме PHP нет ярко выраженного лидера среди фреймворков и, грубо говоря, на каждом новом проекте есть большая вероятность встретить новый для себя фреймворк. И после изучения двух хочешь-нехочешь, но будешь понимать где фреймворк, а где язык.
> Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым монки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше.
То же самое и с разработчиками на PHP-фреймворках…
Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL.
Конечно, весь мир в последние 10 лет как раз работает над упрочением ООП конструкций.
Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.
Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.
Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.
Для высоконагруженных систем не годятся ни руби, ни пхп. Но до высокой нагрузки в 99% процентах случаев есть время и ремурс все переписать правильно.
Поэтому мне странно в сто пятьдесят первый раз читать сравнительные статьи. Это как если бы Вася опубликовал длинную статью о своей возлюбленной, а тут пришел бы Петя и стал с ним спорить: нет, моя лучше. Одинаково хороший и одинаково безобразный код можно напистаь на абсолютно любом языке программирования.
Я в свое время перешел на Rails с PHP по следующим причинам:
1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
3. Удобное из коробки разделение на среды: development, test, production
4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).
Summary: еще один программист посмотрел на мир за пределами своего одного язычка и понял что Ruby ничем существенно не лучше PHP. Но в общем-то и не хуже, поэтому он не готов агитировать за переход на PHP. Если бы он посмотрел немного дальше, то обнаружил бы, что к той же группе относятся Python, Perl и всякие модные node.js.
Очень много всего в кучу собрано, немного прокомментирую.
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».
Я сказал, что по данным WiFi чипа (там не только МАС, который можно подделать, и даже на хабре когда-то была статья по поводу однозначной идентификации WiFi чипов/модулей) можно легко получить данные по IMEI аппарата и, затем, его владельце. Не выходя из подвала КГБ.
В случае с ноутбуком — по модели ноутбука (и серийнике его винды, к примеру, если там винда, а это, чаще всего, так), но я в тот момент думал о портативных устройствах, т.к., обычно, именно с них идёт залив/слив контрафакта через публичные точки.
У всех производителей есть база, куда заносятся серийники всех модулей и блоков в каждом выпущенном аппарате. Официальная версия — для нужд гарантийного ремонта.
В общем, при наличии желания и ресурса, клубочек разматывается довольно быстро.
Чтоб исключить данный риск, ребята жгут ноутбуки/телефоны/флешки. Их цена не сравнима с ценой провала.
ПС. Мак в заминусованном посте, это макдоналдс. На всякий случай…
Я в курсе, и так оно и написано. Я не уточнил по МАС, т.к. помимо него у беспроводных чипов есть ещё несколько параметров, которые можно считать дистанционно и которые оставляют следы.
Не забываем также, что сейчас большинство чипов идут совмещёнными — вифи + блюпуп + рфид и т.п. на одном кристалле.
Таким образом, нет ничего сложного узнать модель аппарата и, часто, владельца (если у вас не краденный в европе аппарат, к примеру).
В любом случае, если вас возьмут лично, живой изъятый аппарат будет доказательством ваших рассылок или чего вы там с него делали.
Ноут в печке рвёт следы. Ты можешь отправить письмо из мака, даже с улицы, но твоё устройство будет идентифицировано хотя бы по данным WiFi чипа, через который пробьют IMEI и через него найдут тебя.
Телеграм изначально позиционировался именно как защищённое средство передачи информации. В пику злым ФСБешникам, оккупировавшим Вконтакт. На деле же (и иначе быть не могло) защищает он лишь на бытовом уровне.
Защиту коммерческой информации мы в году 2001-м делали архивируя винраром с шифрованием AES. Сегодня средств шифрования, в том числе с открытым исходным кодом, которые можно проверить и допилить под себя (добавить XOR, гы) достаточно. И передавай по мылу. Конкуренты не вскроют а от FBI мы, вроде как, и не защищаемся ;)
Засечённый самолёт отвечает открыто, равно как имеет опознавательные знаки на борту. Смысл шифровать? Или враг не откроет огонь, получив в ответ мусор вместо ответа?
Что до секретных приказов, их до сих пор развозят в портупеях, причём по обе стороны океана. Онлайн передача используется лишь в критических по времени ситуациях, когда приказ будет исполнен раньше, чем посылку расшифруют.
--Более того, само по себе использование общедоступных платформ (Android, iOS) уже делают в принципе несекьюрным против правительственных служб.
Да, именно.
Данные передают на флешках. Причём на разъём и контакты наносятся поперечные царапины — если флешку вставить в разъём хоть раз, кромки царапин сминаются и восстановить их нельзя. Минута над микроскопом позволяет понять, совали флеху или нет. Игольчатые и лепестковые контакты также оставляют след на позолоте контактов.
Раз наблюдал картину — менсахеро (пацан лет 15) привозит ноут на мотоцикле. Ноут новый, даже заводская винда ещё не развёрнута.
Разворачивают винду, регистрируют ящик на яху, пишут несколько писем. Ящик удаляют, ноут закрывают и… в печку. Чтоб даже следов мак-адреса сетевухи не осталось.
Это я к чему? Это я к тому, что средства вроде телеграма будут востребованы у Мани, пересылающей фото сиськофф Ване. И опасающейся, что супер-злодей похитит её фото. Но в серьёзном бизнесе, для защиты от FBR, ФСБ и прочих узурпаторов безудержной свободы, ни это, ни любое другое средство шифрования не будет востребовано.
Вообще, есть три цели анализа данных: оценка параметров, прогнозирование данных и сравнение моделей. С помощью байесовских методов можно достичь все три цели.
Из практических примеров, можно назвать следующее, что приходит в голову.
Как писал MAGNUS8, на основе байесовских сетей можно строить системы принятия решений.
Еще одна практическая задача, которой занимаюсь я, состоит в обработке данных физического эксперимента. Есть данные с различных приборов. Причем одни приборы измеряют точно величину параметра, но у них большая неопределенность в координате измерения (то есть измеряют точно, но непонятно где), а другие измеряют в определенном месте, но неточно. С помощью байесовского анализа можно анализировать данные с разных приборов не изолированно, а вместе, за счет чего достигается эффект синергии, и неопределенность в результатах уменьшается.
Еще одна частая задачка в физике и астрономии состоит в следующем. У вас есть сильнозашумленные данные, в которых есть сигналы определенной формы. Но из-за шума вы не можете сказать, в какое время сигналы появлялись и какова их амплитуда. Байесовский анализ в этом поможет.
На основе байесовского анализа вы можете прогнозировать данные. Например, у вас есть исторический тренд какого-то параметра (например, стоимость акций, ВВП и пр.), и вы ходите узнать, с какой вероятностью в следующий момент времени произойдет скачок этого параметра на определенную величину (такой тип задач можно найти и в физике, и в, например, финансах и экономике).
Еще есть замечательная книга D. Sivia «Data Analysis: A Bayesian Tutorial». Она ориентирована на практику, хотя там не рассматриваются вопросы реализации анализа на каком-либо языке.
И, наконец, Andrew Gelman et all. «Bayesian Data Analysis» — это замечательный учебник, хотя в большей степени теоретический.
Сейчас времени не ахти как много, после диплома хочу тоже куда-нибудь это применить. Найти бы ещё простую тему =).
МГУА глянул — очень сильная вещь, буду изучать, спасибо.
Стоит, наверное, сказать, что подобные методы при проектировании алгоритмов требуют достаточно высокой математической культуры разработчика, т.к. малейшая ошибка в выводе и/или реализации вычислительных формул сведет на нет и дискредитирует весь метод. Вероятностные методы особенно этим грешат, поскольку мышление человека не приспособлено для работы с вероятностными категориями и, соответственно, отсутствует «наглядность» и понимание «физического смысла» промежуточных и итоговых вероятностных параметров. Такое понимание есть лишь для базовых понятий теории вероятностей, а дальше нужно лишь очень аккуратно комбинировать и выводить сложные вещи по законам теории вероятностей — здравый смысл для композитных объектов уже не поможет. С этим, в частности, связаны достаточно серьезные методологические баталии, проходящие на страницах современных книг по философии вероятности, а также большое количество софизмов, парадоксов и задачек-курьезов по этой теме.
Еще один нюанс, с которым пришлось столкнуться — к сожалению, практически все мало-мальски ПОЛЕЗНОЕ НА ПРАКТИКЕ на эту тему написано на английском языке. В русскоязычных источниках в-основном только общеизвестная теория с демонстрационными примерами лишь для самых примитивных случаев.
отлично расписано!!! )))
А в чем результат завышен?
Ниже — код для тестирования.
То же самое и с разработчиками на PHP-фреймворках…
Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.
Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.
Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.
Для высоконагруженных систем не годятся ни руби, ни пхп. Но до высокой нагрузки в 99% процентах случаев есть время и ремурс все переписать правильно.
Поэтому мне странно в сто пятьдесят первый раз читать сравнительные статьи. Это как если бы Вася опубликовал длинную статью о своей возлюбленной, а тут пришел бы Петя и стал с ним спорить: нет, моя лучше. Одинаково хороший и одинаково безобразный код можно напистаь на абсолютно любом языке программирования.
1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
3. Удобное из коробки разделение на среды: development, test, production
4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».