Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (4)

Наибольший вклад в теги

Все теги (44)

Лучшие ответы пользователя

Все ответы (72)
  • Действительно ли back-end разработка более консервативна, чем front-end?

    hrls
    @hrls
    Половина ответа в вопросе, но дьявол в мелочах.
    Действительно, для относительно продуктивной backend-разработки практически на любом языке программирования необходимо знать несколько базовых фреймворков и тулов, которые решают большинство задач. Это скелет ~90% приложений сложнее hello world. Хотя и этот скелет меняется и развивается, пусть и не так быстро как хотелось бы, как разнообразные отростки (не консервативность, но более долгий жизненный цикл). Суммарный вес технологий и инструментов не меньше, и уж точно не менее динамично изменяющийся, чем у frontend-разработчиков.
    Далее личный опыт на примере Java.
    Лет 7-8 тому достаточно было знать Spring, Struts, Hibernate да Apache Commons в довесок для разработки большинства решений. Ну и J2EE-стек для задач Enterprise-уровня.
    В году 2014 Spring, Hibernate все также в арсенале программиста, но появилась куча абсолютно новых вещей вроде AMPQ, Hadoop, Netty, Scala с функциональной парадигмой, мультиязычные окружения с Clojure/Groovy/JRuby; стали чаще встречаться альтернативные реализации популярных библиотек (например Guice / Guava); старые технологии вроде J2EE стали использоваться несколько реже. А одних только Key-Value хранилищ, кэшей и прочих NoSQL как грязи. Изменился даже сам подход к построению приложений – мало кто в 2005 слышал про asynchronous event-driven модели и отталкивался при проектировании от REST-стиля (собственно, там и корни frontend-девелопера как отдельной специализации). Про эволюцию систем сборок, VCS, бенчмарков и прочих "микро"-элементов можно расписывать не одну простыню.
    И да простят меня frontend-товарищи за, возможно, чванливый тон, но раскурить тонкости работы async IO в зависимости от ОС-специфики вроде epoll/kqueue или учитывать CAP-теорему при построении middleware-кэша это уровнем сложности повыше, чем новый CSS-препроцессор и CoffeeScript c очередным MVC / MVVM-фреймворком. Некоторые задачи, вроде синхронизации потоков, так и вообще лежат большей частью в области математики.
    Уверен, что и в frontend-разработке существуют задачи сложнее и интереснее поехавшей на пиксель верстки и обновления полей после парсинга JSON, но ИМХО backend-разработка ближе к системному программированию старой школы, в то время как frontend суть прикладное программирование с примесями дизайна.
    Frontend-инструментов больше, backend-инструменты сложнее.
    Ответ написан
  • Почему нет вопросов по GRASP паттернам(принципам) на тостере?

    hrls
    @hrls
    Это от того, что на тостере преимущественно обитают полные нубы, которые не могут потратить полчаса на изучение проблемы и поиск решения, а предпочитают сходу задавать вопросы и получать решение, либо же кретины с вопросами вида "план обучения %PROG_LANG%" или "мне 100500 лет, я водитель такси, Java - не поздно ли?". Такие обитатели еще не доросли до GRASP.
    А по существу - GRASP действительно более абстрактные в сравнении с GoF и не настолько четко выражаются кодом. От чего и имеют область определения в головах программистов с бородами, которые и без помощи Q&A могут вспомнить примеры из личного опыта и найти решение.
    Ответ написан
  • Как создать свой формат файла или как сохранить 300 вопросов с вариантами в одном файле?

    hrls
    @hrls
    Не вижу проблем с хранением всего в JSON-файле с кодированием бинарных данных в Base64 (так изображения хранить проще простого; про формулы в конце). JSON парсить в php (да и вообще) – проще некуда. Сохранение в JSON-файл из *.doc/docx можно реализовать макросом-скриптом на Visual Basic за половину рабочего дня.
    Если не планируется какое либо распространение этого софта и заранее известно окружение (например система тестирования в университете с определенной версией MS Office =) ), то можно использовать автоматизацию приложений MS Office. Насколько помню, на том же Delphi довольно просто прикручивался кастомный GUI к документу MS Office при наличии хоть какого опыта работы с технологией COM. В таком случае достаточно будет лишь правильно разметить документ. С веб-версией, в случае ее необходимости, придется обращаться к .NET-платформе (хотя наверняка в MSDN уже есть мануал с сорцами на эту тему).
    И стоит напомнить: *.docx – это не более чем переименованный *.zip с файлами в xml-формате. Не знаю как там хранятся изображения, но парсить распакованную структуру не должно составить большого труда средствами любого языка программирования.
    Что является формулами я не смог понять из вопроса. Если объекты *math* или как там в MS Office они зовуться, то тут нужно искать решение. Например отрендерить предварительно =)). Вроде когда из .docx импортировали в *.doc для Office 2003 так и было.
    Ответ написан
  • C чего начать изучение scala?

    hrls
    @hrls
    "Scala для нетерпеливых" годится как entry-level manual, книгу Одерски прочитать в любом случае придется. ИМХО Одерски как первая книга скучна и не очень, но вот со средних размеров багажом читается просто отлично. Багаж можно наполнить чтением сорцов самой скалы, на уровне посмотреть как работают базовые классы и коллекции (когда учил ставил эксперименты вроде "а как бы я это реализовал сам с теми знаниями что у меня есть сейчас", лез читать код и просветлялся). Если что-то читается тяжело, то лучше это пропустить – не вся библиотека блещет красивыми и логичными решениями, некоторые решения просто удивляли (описываю 2.10).
    Может это сугубо персонально, но код на скале читается просто очень легко, если автор преследовал такую цель (имею ввиду стандартную библиотеку).
    Про spray не скажу, но у проекта typesafe вроде как очень хорошая документация с туториалами.
    Из книг можн пробежаться по Functional Programming Patterns in Scala and Clojure, если маловат опыт в функциональном программировании и планируется активное использование этой парадигмы.
    Ответ написан