• Есть ли основные правила супер оптимизации?

    smart
    @smart
    вы меня знаете
    Тут хорошо ответили про оптимизацию написанного приложения и про то, что не надо с ней торопиться. Но также очень важно до начала написания кода правильно спроектировать архитектуру вашей системы. На задачах какого масштаба она будет использоваться? В каком окружении она будет работать? Какие требования к отказоустойчивости и резервированию?

    Все эти ответы могут существенно повлиять на архитектуру решения. Например, если вы пишете код, заточенный под работу в носимом девайсе на конкретном ARM-процессоре (какой-нибудь очередной умный браслет) – вы можете применить одни подходы (изучить железо, оптимизировать под него на низком уровне). А если вы делаете коробочный продукт, который будет работать в гетерогенной среде (например, антивирус, который запустят на самых разных машинах и системах) – то вам становится важнее добиться надежности и производительности "в среднем".

    Аналогично, если вы делаете софт, запускающийся в один поток на одном компьютере – это одно, а если проектируете систему, которая будет работать параллельно на десятках ядер на сервер и сотнях этих серверов, стоящих в одном дата-центре – совсем другое (а если не в одном, а в разных дата-центрах, то вообще третье).
    Ответ написан
    Комментировать
  • Как работать с базой в приложениях на Tornado?

    smart
    @smart
    вы меня знаете
    Кажется, в Вашем вопросе скрыто сразу несколько. Попробую их вычленить и дать ответ.

    1. Стоит ли писать полностью асинхронное приложение? Или стараться сделать синхронно работающее, но быстрое? Ответ зависит от специфики приложения.

    Важно понимать, что во многих случаях за счет асинхронности вы не ускоряете ответ приложения на внешний запрос: если для ответа на запрос приложению надо сделать запрос в mongodb и на основе полученных данных - запрос в mysql, то вы все равно не ответите наружу раньше, чем выполните эти два запроса. По сути, в этом случае вы экономите только память (и немножко - процессор), потому что вместо 40 параллельно запущенных процессов, отвечающих на запросы, можете запустить, скажем, 4 (по числу ядер).

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

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

    2. Какую СУБД использовать? Много про это написано, но опять же - исходя из задач. В последние годы NoSQL-базы очень хорошо развились и предлагают интересные возможности. Например, если писать чат с прибамбасами, то может пригодиться механизм publish-subscribe (есть в явном виде в redis, также реализуется на mongo и других). Если масштаб проекта большой и нужно масштабирование и надежность, то стоит посмотреть на riak и aerospike (они хорошо скейлятся в многосерверные конфигурации). И т.д. и т.п. - если надо, напишите подробнее о проекте, подумаем.

    3. Как работать с данной СУБД конкретно из python? Я не большой специалист именно по python, но насколько понимаю, есть библиотеки для асинхронной работы как с SQL-СУБД (по крайней мере, для Postgres), так и с NoSQL (по крайней мере, есть для Mongo и для redis).
    Ответ написан
  • Графический дизайнер хочет переквалифицироваться в веб дизайнера. Что надо знать?

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

    В простейшем случае от дизайнера нужна картинка, пригодная к верстке. Это означает файл в формате .psd с макетом сайта (так, как он будет выглядеть в браузере). Картинка должна быть в растровом (пиксельном) представлении - это, кстати, камень преткновения многих полиграфических дизайнеров (они привыкли мыслить в векторе и "точках на дюйм" - здесь же просто "пиксели"). Также в отличие от полиграфии, важно думать о сайте не как о статичной картинке, а как об интерфейсе взаимодействия с посетителем: что происходит, когда юзер наводит мышку на ссылки, когда кликает и т.п. В последние годы (с развитием retina и прочих 4k) также важно, чтобы растровая картинка была с "запасом" по разрешению (т.е. все отрисовано во в 2-4 раза большем разрешении).

    Очень важно, чтобы дизайнер понимал специфику верстки (и/или плотно общался с хорошим верстальщиком), чтобы он предусмотрел, что происходит при изменении размеров окна браузера, как выглядит сайт на очень больших и очень маленьких экранах и т.п. Особенно это важно, если верстка "тянущаяся" (как именно позиционируются элементы и контент страницы при изменении ширины браузера). Чтобы хорошо понимать возможности верстки, рекомендую изучить основы html и css, например вот очень простой начальный курс: www.codecademy.com/skills/make-a-website - а вот тут чуть более сложные (но тоже начальные) уроки: https://www.codeschool.com/paths/html-css

    Теперь о другой стороне. Если речь идет не о том, чтобы "рисовать сайты", а о том, чтобы создавать и поддерживать интернет-сервис (например, социальную сеть) - то тут дизайнер становится не столько художником, сколько проектировщиком. И проектирует он "пользовательское взаимодействие" (user experience) - то есть процесс того, как юзер общается/работает с проектом, со всеми возможными вариантами, ветвлениями и т.п. Кстати, в больших проектах роли графического дизайнера (который рисует кнопки, иконки и т.п.) и дизайнера-проектировщика часто разделены - но для эффективной работы обоим надо понимать роли друг друга. Вот тут уже особенно важны понятия "responsiveness", предсказуемость поведения, единый стиль интерфейса, который понятен и привычен пользователю.

    Когда речь идет о жизни большого проекта, дизайнер чаще улучшает и дополняет то, что есть, чем переделывает с нуля. Поэтому результат работы для такого дизайнера - это макет, который "совместим" с текущим состоянием проекта и не требует существенной переверстки. Часто это по прежнему .psd, иногда это просто прототип (например, в том же axure), на базе которого верстальщик собирает интерфейс из уже готовой и отработанной (для данного проекта) библиотеки элементов.

    Ну и независимо то того, над каким проектом работает веб-дизайнер, имеет смысл поискать интересные решения на https://dribbble.com/, https://www.behance.net/ и подобных сервисах.
    Ответ написан
    1 комментарий
  • Какие порекомендуете статьи на русском про архитектуру WEB-приложений?

    smart
    @smart
    вы меня знаете
    Недавно был аналогичный вопрос и я писал развернутый ответ к нему: Как повысить знания в области архитектуры веб проектов?

    Повторю вкратце: много информации есть в открытом доступе, начиная от вводных статей начального уровня (типа habrahabr.ru/post/15362 - моя очень давняя публикация), заканчивая докладами с конференций, на которых разбираются и глубокие частные вопросы.

    Например, в интернете доступны записи с многих технологических конференций:
    https://techforum.mail.ru/video/
    https://tech.yandex.ru/events/yac/
    ritconf.ru/archive и www.highload.ru (тут видеозаписей нет, но есть слайды почти всех презентаций)
    Ответ написан
    Комментировать
  • Есть ли сервис или библиотека для составления предложений из слов?

    smart
    @smart
    вы меня знаете
    Все зависит от того, какую конечную задачу Вы хотите решить.

    Конечно, подобные алгоритмы и библиотеки есть - начиная от примитивных развлекалок: martynov.info/textgen (просто составляет куски фраз в случайном порядке - см код в исходнике страницы), до сложнейших научных работ www.siggen.org (это сайт группы компьютерных лингвистов).

    Если хочется покопаться в теме NLG (natural language generation), начать стоит с алгоритмов генерации на основе цепей Маркова (неплохое объяснение основ - www.manhunter.ru/webmaster/358_generator_teksta_na... и сетей Байеса.

    Если собираетесь глубоко погрузиться в эту тему, не обойдетесь без KPML - www.fb10.uni-bremen.de/anglistik/langpro/kpml/READ...

    www.nlg-wiki.org/systems - вот тут большой перечень разных систем для NLG. В частности, нашлась какая-то (похоже, заброшенная) система "Душка" - https://code.google.com/p/mindforth/wiki/RussMan

    Возвращаясь к исходному вопросу про js-библиотеку - сам на js глубоко заниматься генерацией не пробовал, но нашел таких штуки:

    https://github.com/NaturalNode/natural - библиотека (довольно низкоуровневая) для работы с натуральным языком (заявлена поддержка русского)

    rednoise.org/rita - библиотека для работы с натуральным языком с приличной базой данных слов, синонимов и т.п. (только английский)
    Ответ написан
    2 комментария
  • В фриланс за 5 месяцев – реально ли (с учетом имеющихся знаний + помощь в выборе между двумя направлениями)?

    smart
    @smart
    вы меня знаете
    Короткий ответ: реально.

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

    А вообще, напишите мне - может предложу проекты .)
    Ответ написан
    Комментировать
  • Как построить базу данных под личные сообщения?

    smart
    @smart
    вы меня знаете
    Главный вопрос - каковы планируемые характеристики системы? Сколько юзеров, сколько сообщений, какая нагрузка чтение-запись, сколько надо хранить сообщения, какие требования по отказоустойчивости, наконец, какие ресурсы для разработки доступны и т.п.

    И исходя из этого можно дать советы. Подозреваю, что главным советом будет вопрос - а зачем вам mysql? Есть множество способов организовать механику и хранение чата более эффективно: redis (в нем есть механизм publish/subscribe, удобный для организации чатов), mongodb (тоже можно сделать pubsub через tailable cursor), riak (шикарно скейлится) и так далее.
    Ответ написан
    Комментировать
  • Как повысить знания в области архитектуры веб проектов?

    smart
    @smart
    вы меня знаете
    Учитесь на ошибках - своих и чужих. Как правильно сказали рядом, практика - это главное. Проектируйте системы - свои, чужие - лучше реальные, но можно и вымышленные.

    Очень полезно начать с рассуждений "как бы я спроектировал поиск Яндекса, почту Mail.Ru, френдленту ВКонтакте". Продумайте архитектуру - а потом расскажите свое видение разработчикам этих систем и спросите, как на самом деле сделано у них и почему (вот увидите, многие с удовольствием ответят).

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

    Ну а еще про "чужие ошибки" - многие проекты с удовольствием рассказывают в интернете и на конференциях. Читайте их статьи, смотрите доклады - в интернете доступны записи с многих технологических конференций:
    https://techforum.mail.ru/video/
    https://tech.yandex.ru/events/yac/
    ritconf.ru/archive и www.highload.ru - тут видеозаписей нет, но есть слайды почти всех презентаций

    В общем, в сети как обычно большой и интересный объем информации, многое из которого представляет ценный опыт.
    Ответ написан
    2 комментария
  • Посоветуете русскоговорящие аналоги взамен обезумевшего free-lance.ru?

    smart
    @smart
    вы меня знаете
    Уже отвечали по ссылкам выше, но еще раз про моих друзей: profilink.com/ — они сегодня дают свой «золотой аккаунт» всем, у кого был pro на фрилансе.
    Ответ написан
  • Какие возможности вы хотели бы видеть на фриланс-бирже?

    smart
    @smart
    вы меня знаете
    Коллеги, есть дружественный проект Профилинкhttp://profilink.com/ (сейчас я его сюда призову).

    Они хорошие ребята, фактически только недавно открылись, и готовы прислушиваться к мнениям, советам и идеям профессионалов. Можно в рамках этого хорошего сайта силами крауд-мозга создать идеальное пристанище для фрилансера!
    Ответ написан
  • Mail.ru съедает часть ссылки в письме?

    smart
    @smart
    вы меня знаете
    Константин, в Вашем случае проблема возникает из-за того, что в письме атрибут href не взят в кавычки (href=http://www.mysite.ru/gallery/show_foto.php?x=8013). Если взять в кавычки (href=«www.mysite.ru/gallery/show_foto.php?x=8013») — то будет работать нормально. Это не очень хорошо с нашей стороны, и мы посмотрим, как можно решить эту проблему — но вообще, лучше всегда брать атрибуты в кавычки — так надежнее.
    Ответ написан
    Комментировать