Контакты

Достижения

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

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

Все теги (108)

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

Все ответы (156)
  • Какие самые реальные и действенные проекты\работы\фриланс для python-программиста?

    voidnugget
    @voidnugget
    Программист-прагматик
    Пишу на питоне ещё с 15 лет (2.4+)... ненавижу его runtime и архитектуру. Язык хороший - реализация никакущая. Ну да его синтаксис достаточно упрощён, но и за синтаксический сахар приходится платить сложностями отладки и поддержки.

    Сейчас же почти все известные мне конторы не используют питон в продакшенах с более-менее высокой нагрузкой. Яндекс тому пример. Чаще питон используется для решения прикладных задач администрирования, так как это делается, к примеру, в SaltStack. Все дружно слезают с питона, РНР и рельсов на Golang, Java/Scala, и иногда даже Groovy - производительность выше в десятки раз, и managed runtime на много стабильнее. Правда в случае с JVM очень сильно раздувается куча в виду избыточности объектной модели (оператву жрёт как дурное, а я байтики считать привык). Сейчас это должно лечится с помощью Project Graal и Truffle, правда пока до этого дошёл только jRuby, который тоже в пару десятков раз быстрее Ruby. По идее и Groovy тоже должен переползти как-то ... Вот про jyton ничего не знаю.

    Много моих знакомых слезло на Golang с Ruby и Питона.
    Стоит попробовать - он достаточно простой и идиоматичный, вот рефлексию стоит обходить стороной - она очень медленная, впрочем как и везде. Работу может и не найдёте сразу, но после реализации пары простых проектов будет проще предлагать в качестве целевой платформы.

    Фрилансить с питоном начать можно, но очень желательно опробовать ещё хотя бы пару окружений и фреймворков типа Groovy Grails, или Typesafe Stack. Сейчас требования рынка возросли в пару раз за последние два года - нужны ассинхронности/многопоточности, push-нотификации в мобильные приложения и по вэбсокетам/комету. И это всё с богатыми js-фронтендами на всяких там Angular'ах и React'ах. Естественно можно крутить костыли типа Celery / Gearmand / Beanstalk / RabidMQ, но накладные расходы на коммуникацию слишком большие :( Компилируемые языки со своими Managed Runtime'ами позволяют строить монолитные приложения в которых подобные решения избыточны в рамках одной и той же машины, а если это куча нод в кластере то нужно мерить/думать.

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

    А вот с pyramid (pylons) и SQLAlchemy можно строить достаточно хорошие приложения. У них есть enterprise поддержка и соответствующие гарантии.

    Типовые задачи на питоне:
    - написать какой-то мелкий скрипт с Gui на PyQT / Pyside для какой-то аналитики и отрисовки графиков, иногда попадаются задачки с gstreamer'ом
    - написать какое-то простое RESTful CRUD приложение, в стиле "одна табличка БД - один контролеер", это конечно же тонна копипасты и мне больше нравятся DataMapper'ы по типу TastyPie. Иногда люди хотят чистого Tornado или Flask'a, так как им не нравится overhead в джанге и pylons.
    - написать скрипты для деплоя чего-то, обычно люди не знают про SaltStack.

    В плане архитектуры питонистам чужды различные SOA с CQRS-ES'ом, потому что сам компилятор не располагает. Хотя её достаточно просто поддерживать.

    Проблема всех проектов на Node.js / Python / Ruby это отсутствие долгосрочной поддержки библиотек и фреймворков - часто ломается обратная совместимость, и нужно постоянно следить за состоянием всех зависимостей. Опять же нужен TDD/BDD для того что это всё хорошо контролировать. Тестируешь руками - себя не уважаешь.

    Ну и вроде всё ...
    p.s. я опубликую на хабре статью сегодня-завтра "Freelance - you're doing it wrong" там поделюсь опытом работы и основными организационными проблемами в рамках удалённой работы и фриланса, покажу разницу между ними.
    Ответ написан
    6 комментариев
  • С чего начать изучать BigData?

    voidnugget
    @voidnugget
    Программист-прагматик
    BigData не очень то и связана со структурами данных - в основном это разнообразные пространственные структуры, скорее больше связана с алгоритмами NLP, классификации и машинного обучения.

    В первую очередь нужно выбрать средство обработки и хранения.
    В случае с Java это HBase Cassandra
    HBase - когда пишется в базу очень много, и большинство индексов "самодельные".
    Cassandra - когда соотношение чтения / записи 4:3, так как в Cassandra уже есть средства колоночной индексации.

    В случае с реальным высоконагрузом это ScyllaDB - обладает теми же особенностями что и HBase, но С++11 и Share-nothing approach и от того в 6-7 раз шустрее.

    Для БД до 200Гб хватит банального MySQL'я c R-tree индексом и Engine Archive.
    Вот PostgreSQL при правильной настройке спокойно строит B-tree индексы для объёмов данных в 500-700Гб, что для MySQL'я непосильная задача Ну и в PostgreSQL часто приходится дописывать сишные функции агрегации и строить по ним разнообразные индексы, иногда пространственные (gin/gist).

    Вот небольшой обзор разных типов индексов.

    От себя ещё добавлю MVP-tree для поиска похожих персептивных хэшей и Fusion-tree как более съедобный вариант дерева Ван Емде Боаса.

    По поводу хипстер-культа вокруг MongoDB - скажу что PostgreSQL с индексами на хэш-таблицах и небольшими множествами документов в 1.5-3 раза шустрее, потому что "Building Index with Vodka". А нормальная репликация и партицирование напрямую зависит от принципов решения задачи Консенсуса в каждом конкретном приложении, и без понимания работы Raft / Paxos не стоит надеятся на чудеса той же MongoDB или PostgreSQL, они являются не более чем инструментами для решения этой задачи.

    MongoDB очень даже ничего для реактивных проектов на основе Meteor, а для всего остального уже GoldenHammer™.

    По индексации, надо обязательно-обязательно прочитать книги Ханны Самет
    Foundations of Multidimensional and Metric Data St... = Applications of Spatial Data Structures: Computer ... + The Design and Analysis of Spatial Data Structures

    В принципе книжки Foundations of Multidimensional and Metric Structures должно хватить с головой, но можно "дочитывать" более полное описание в более древних работах. Одним словом тётка "жжёт", и я не знаю почему это до сих пор никто не перевёл.

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

    По машинному обучению можно пройти курс Эндрю Ына на курсере.

    Есть Южный DataScience-централ, там есть много чего полезного. Его можно почитывать. Есть ещё поверхностные CheetSheet'ы, видел и получше, но не нашёл.

    Как DeepLearning адепт советую разобраться с Theano, и методами описанными тут. В продакшенах эта штука до безобразия слоупочна и видел товарищей которые более-менее успешно слезли на Neon.

    Если лезть в Java, то на примере Spotify чаще всего используются связки
    Apache Kafka -> Apache HBase -> Apache Storm -> Apache Spark (mllib) -> Apache HBase -> Apache Phoenix -> Hibernate + любой MVC фреймворк и т.п.

    Естественно об относительно высокой производительности и хорошем вертикальном масштабировании речи не идёт, если брать C++11 ScyllaDB -> Neon хорошо отпрофилировать и допилить, можно получить в 3-5 раз выше производительность и соответственно гораздо меньшие задержки, но обычно всем влом. REST API под такое обычно пытаются писать на сях (без плюсов) в виде расширений под Nginx, что является довольно породистым извратом - в большинстве случаев банального golang/netty будет достаточно.

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

    По поводу HA и Zookeeper можно увидеть много срача, особенно в Netflix'e, по этому для менеджмента высокой доступности лучше использовать именно их решения - eureka или для отказоустойчивости Hystrix. Хотя я не могу сказать что это достаточно зрелые проекты - в них тоже хватает изъянов, но они на много шустрее остальных Apache поделок.

    Нельзя делать одновременно отказоустойчивые и высокодоступные приложения - потому что CAP теорема имеет место быть.

    Ещё есть очень тонкий момент с Java в целом - нужно минимизировать время сборки мусора и лезть в offheap, стоит глянуть как реализованы буферы в netty - это arena аллокатор по типу того что используется jemalloc и различная misc.unsafe ересь. Можно ещё пробовать Hazelcast / Terracotta, но принципиально там тоже самое, только платно и "расспределённо".

    Для REST API я чаще всего использую Vert.x и ванильную Java.
    Overhead от Scala довольно таки большой, а время компиляции просто вырвиглазное.
    Для минимизации копи-пасты вполне безопасно использовать Groovy c @ Immutable и @ CompileStatic.
    Но в Vert.x'e он весь "динамичный" :|

    Я ничего не могу сказать по поводу производительности Clojure, он местами через чур invokeDynamic. Естественно что ванильная Java будет шустрее, но я без понятия на сколько.

    Желаю Вам приятного вечера.

    p.s. не везде проставил ссылки просто потому что хочу спать.
    Ответ написан
    4 комментария
  • Как стать хакером в 2015-ом?

    voidnugget
    @voidnugget
    Программист-прагматик
    В принципе хакерские скилы ничем примечательным в наше время особо не отличаются от того что было 10 лет назад. Нужно знать ассемблер и сишку - без плюсов и досконально, что бы фраза "Си (без плюсов) может быть очень даже ООП" не могла вызвать странную ухмылку на вашем лице и воспринималась довольно обыденно.

    1. Перво-наперво нужно научится пользоваться отладчиком OllyDbg, IDA и т.п.
    2. Потом нужно разобраться в архитектуре х86 на уровне понимания распределения прав доступа, работы с памятью и различных SIMD/MIMD операций.
    3. От ОС ничего не зависит - знания и навыки в kmdf/umdf и linux kernel device drivers дополняют друг друга. Также нужно разобраться с системными вызовами самих ОС и как это всё оперируются со стороны старых добрых glibc и т.п. вещей.
    4. Из языков нужно брать и эксперементировать со всем - даже в той же Java в рамках OpenJDK есть куча эксперементальных вещей, типа Project Graal и Project Sumatra, в которых очень даже полезно покулупаться ради собственного развития. Никогда не знаешь что найдёшь и как это можно будет потом использовать - главное искать и не останавливаться.
    5. Конвертируют полученные навыки и знания самыми разнообразными способами - лучше всего разрабатывать под ядрышка ОС различные вундервафли, становиться известным и ити работать в IBM / Intel. WhiteHat/GreyHat зароботки в постсовке нереальны, а BlackHat грозит сроком.
    Ответ написан
    Комментировать
  • Какой выбрать язык для серверной части highload проекта?

    voidnugget
    @voidnugget
    Программист-прагматик
    Когда люди называют 1Гбит динамического http трафика highload'ом - это вызывает у меня довольно нелепую ухмылку.

    Сравнивать php / python / ruby более-менее целесообразно так как это полностью интерпретируемые языки с кэшированием байткода, иногда с оптимизациями, как в случае с jRuby и Project Graal. Обычно такие вещи помирают на 14-17К запросов в секунду с пустыми ответами... В общем на одном гигабите трафика тут обычно всё и заканчивается. Node.js по производительности более корректно сравнивать с JVM языками типа Groovy или Scala, но никак не с самой Java. На практике через Netty на Disruptor'е под offheap'ом и Terracotta можно пропустить и 40Гбит живого трафика, без статики, - главное правильно профилировать и писать прямо pfRing.

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

    Если вы хотите строить что-то действительно стоящее - стоит смотреть в сторону CQRS-ES'a и реактивных приложений в рамках SOA. Возможно внедрение микросервисных архитектур если нет требований к задержкам на выполнение запросов. Но, учитывая что вы задаёте здесь вопросы о том "что лучше node.js или python" не думаю что у вас хватит опыта для построения подобных вещей.

    Можно пробовать golang - яндекс слез с python'a на golang по причине слоупочности оного, и довольно хорошо так слез. В golang'е сейчас самый лучший RAD, гораздо круче того же node.js. Идеоматичность самого языка решает достаточно много потенциальных проблем ещё на этапе разработки. Да и сообщество сейчас довольно активно пилит его runtime - внедряют многопоточный gc и ещё пару вкусностей. Даже не умея всех этих асинхронностей и прочей лабуды с golang'ом можно получить довольно хороший выхлоп. Правда меня немного смущает отсутствие нормальных datamapper'ов и scaffolding'a под golang.
    Ответ написан
    16 комментариев
  • Разработка под android для веб-программиста - с чего начать?

    voidnugget
    @voidnugget
    Программист-прагматик
    Сore Java - первый и кусочек второго тома
    Effective Java Джошуа Блоха - обязательно
    Java Concurrency in Practice Браяна Гоетса - обязательно
    из серии Pragmatic Programmer
    Programming Concurrency on the JVM: Mastering Synchronization
    Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions
    Pragmatic Unit Testing in Java 8 with JUnit
    Ответ написан
    4 комментария

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

Все вопросы (2)