Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 17381 сообщений
Cообщения с меткой

программирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Что послушать программисту? Подборка подкастов на русском и англиском языках

Четверг, 25 Августа 2016 г. 16:33 (ссылка)

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



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



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



Давайте нечнем с русскоязычных подкастов, взглянем на список!



Разбор Полетов





Этот подкаст обычно ведут Виктор Гамов, Алексей Абашев, Дмитрий Чурбанов, а также различные гости, например, парни из гугла. Обсуждают новости мира IT и новые программные продукты, в целом о технологиях, гаджетах и программировании. Подкасты обычно длятся минимум 2 часа.



Радио-Т





Радио-Т один из первых технических подкастов на русском языке. Ведущих в подкасте четверо, иногда приглашаются для беседы и другие известные личности. Подкаст ориентирован на широкую техническую аудиторию и освещает самые разные современные тенденции и вопросы в ИТ, основные новости и события, при этом иногда точка зрения ведущих в шоу может различаться, что позволяет взглянуть на предмет с разных сторон, к тому же, все участники шоу достаточно профессиональны, чтобы их точка зрения и мысли были интересны всем, пусть даже вы можете не разделять их мнение по какому-либо вопросу. Вещают раз в неделю, в субботу, 23:00 по МСК.



РадиоJS





Как вы уже догадались, подкаст о JS. В каждом выпуске обсуждают последние новости из мира JS. Время от времени приглашают гостей, знатных профессионалов, дабы те поделились своим опытом. Говорят о библиотеках и фреймворках, последних тенденциях и приёмах “старой школы”. Каждый выпуск длиной от 30 до 60 мин.



Software Development podCAST





Это один из немногих IT подкастов, в котором обсуждается исключительно программирование. В записи каждого выпуска принимают участие 2 человека – ведущий и гость. Из гостей бывают: директор одного из админ отделов Mail.ru, разработчик фронтенда сбербанка, разработчик фронтенда ostrovok.ru и другие интересные люди. Тут можно услышать разговоры о функциональных языках это и фронтенд разработка, и хардкор в виде C++, и многое другое.



The Art Of Programming





Подкаст ориентирован на программистов и тех, кто просто интересуется этим: студентов, начинающих разработчиков которые только познают мир паттернов. Кроме таких важных для разработчика проблем, автор подкаста рассматривает и различные книги, которые вам могут пригодится, освещает интересные материалы из сети. Выходит подкаст раз в неделю и длится в среднем 15-20 минут.



Android Dev





Подкаст о разработке под Android и всем, что с этим связано. Гости программы — разработчики с большим опытом и стажем, которые помнят Android ещё молодым и зелёным, когда он еще был версии 1.5. За эти годы они написали приложения для миллионов пользователей по всему миру. В подкасте говорят о разработке во всех ее аспектах, от нарезки дизайна до сборки собственных прошивок.



RWpod





Подкаст о Ruby и Ruby on Rails. Ведут Алексей Васильев и Александр Чаплинский, разработчики из компании Railsware. Подкасты выходят по вторникам и длятся от 30 до 60 минут, на данный момент записано 32 выпуска.



IT-мысли



Ведет один из сотрудников компании Яндекс, Сергей Петренко, он же является и со-ведущим Радио-Т. Само шоу интересное с точки зрения именно анализа определённых событий на ИТ-рынке, собственно, из названия шоу это и следует. Если вам интересно услышать оценку и анализ событий на мировой ИТ-арене с акцентом на веб и поисково-рекламные технологии, да ещё с уст одного из высокопоставленных сотрудников компании Яндекс, этот подкаст заслуживает внимания. Выпуски длятся от 30 до 50 минут и выходят раз в неделю.



Solo на .Net



Подкаст ведёт опытный c# разработчик Дмитрий Нестерук. Как видно из названия, больше всего обсуждаются вещи, связанные с программированим на стеке технологий .NET. Однако часто бывают небольшие ответвления в сторону чего-то айтишного, без привязки к платформе. Подкаст выходит два раза в месяц.



Откровенно про IT карьеризм



Разговорное шоу с интересными собеседниками, о программировании, карьере и всем что связано с IT.



Далее давайте рассмотрим список подкастов на английском языке:



Programming Throwdown





На Programming Throwdown обговаривают широкий круг вопросов, связанных с программированием в интересной и привлекательной манере. Programming Throwdown это обучающие подкасты от популярных программистов. Каждое шоу охватывает новый язык программирования. Каждый эпизод длится 60 минут.



Full Stack Radio





Full Stack Radio — это отличный подкаст для разработчиков, заинтересованных в создании больших программных продуктов. На каждый новый эпизод приглашают гостя, это похоже на интервью но в более развлекательной и образовательной форме. Каждый эпизод длиной от 30 до 60 минут.



Coding Blocks





Подкаст от трех профессиональных разработчиков, на Coding Blocks затрагивают абсолютно различные темы из области разработки, например: лучшие практики программирования, понимание алгоритмов и парадигм, шаблоны проектирования, и многое другое! Этот подкаст будет интересен всем программистам, хотя есть небольшой уклон к C # и .NET.



Arrested DevOps





Подкаст Arrested DevOps, ведут поможет вам расширить понимание, узнать о новых, полезных практиках в разработке и достичь максимального успеха с вашей командой или организацией. Каждый эпизод длиной 60 минут.



Software Engineering Daily





Software Engineering Daily это подкаст с интервью который охватывает все стороны программной инженерии. Вот как его описывает сам ведущий: «После каждого эпизода, вы будете как минимум на 1% лучше понимать, как работает программное обеспечение». Один выпуск длиться 60 минут.



Software Engineering Radio





Software Engineering Radio, подкаст предназначен для профессиональных разработчиков программного обеспечения. Раз в 10 дней, выходит новый выпуск, который охватывает все темы программной инженерии. Каждый выпуск обеспечивает глубокое погружение в определенную тему, также часто можно услышать интервью с известными специалистами в области разработки программного обеспечения. Подкаст выступает как прочный образовательный ресурс для разработчиков, темы на котором варьируются начиная от динамических языков, заканчивая .NET и облачными сервисами.



Hanselminutes





Его описывают как «свежий воздух для разработчиков» этот еженедельный подкаст содержит интервью и дискуссии о web, образовании и IT. Скотт Хансельман, еженедельно собирает свежие идеи и великих людей. Шоу предлагает обзор широкого спектра технологий и подходов в области разработки.



This Developer’s Life





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



CodeNewbie





CodeNewbie отличный подкаст для новичков в мире разработки! В нем можно услышать много историй о людях, которые прошли дорогу от начинающего разработчика до профессионала. Много разнообразных гостей, которые добавят мотивации новичкам, и тем, кто только планирует стать программистом. Одним словом, это вдохновляет. Каждый эпизод длиной в 60 минут.



The Changelog





Подкаст, в основном, охватывает широкий спектр инструментов разработки с открытым исходным кодом и новости связанные с программированием. Подкаст имеет большой уклон на веб-разработку, начиная от Ruby и Node.js, и заканчивая JavaScript, CSS, также охватывает широкий спектр инструментов, от Git и до npm. Каждый эпизод длиной от 60 до 90 минут.



Learn to Code with Me





Автор Лауренса Брэдфорд, front end разработчица и самоучка. Подкаст ориентирован на новичков, которые имеют мало практического опыта в программировании. Каждый эпизод длиной 30 минут.



The Bike Shed





Подкаст в основном сосредоточен на веб-разработке. Каждый эпизод, три ведущих приглашают гостя, дабы тот рассказал о своем опыте и проблемах, с которыми он сталкивался во время работы с JavaScript, Ruby, Rails и т.д. Длительность выпуска от 30 до 40 минут.



AppMasters





Подкаст создан успешным разработчиком приложений и маркетологом, он может помочь вам с проектированием, разработкой и даже маркетингом ваших мобильных приложений. Отлично подойдет разработчикам, которые знают, как создавать приложения, но не уверены в том, как их продать или сделать привлекательными для потенциальных клиентов. Каждый выпуск длится 30 минут.



The Debug Log





Подкаст о разработке игр трудно найти в эти дни, не столько потому, что они редкое явление, сколько потому, что большинство так называемых «Gamedev подкастов» больше о дизайне, чем об процессе разработки. И именно поэтому The Debug Log замечательная находка.



Этот подкаст о создании игр с использованием Unity, но в некоторых выпусках обговаривают разработку и на других движках. Каждый эпизод длится приблизительно 40-60 минут.



CppCast





Этот подкаст является обязательным для прослушивания всем любителям C++. CppCast является самым популярным, англоязычным подкастом для C++ разработчиков. Выпуски длиной от 30 до 60 минут.



.NET Rocks!





Как вы уже поняли .NET Rocks это аудио-шоу для Microsoft .NET разработчиков. Это подкаст-приложение ориентировано на профессиональных разработчиков программного обеспечения, ИТ-специалистов или тех кто интересуется техникой и программированием. Служит источником последних новостей, дискуссий, секретов, приемов и инсайдеров для профессионального саморазвития. Каждый выпуск длится 60 минут.



JavaScript Jabber





Каждый JavaScript разработчик должен хоть раз прослушать этот подкаст. Подкаст представляет собой еженедельное обсуждение JavaScript. В нем также рассматриваются методы программирования, среды програмирования и сообщества связанные с технологией. JavaScript Jabber также углубляется в такие темы, как CSS, TypeScript, IDE, базы данных и многое другое. Каждый выпуск длится примерно 40 до 60 минут длиной.



Talk Python to Me





Python простой но странный язык программирования, его не сложно изучать, но им трудно овладеть. Этот еженедельный подкаст ведет Майкл Кеннеди и он охватывает широкий спектр вопросов связанных с Python, а также многими смежными темами, такими как AngularJS, DevOps, MongoDB. В целом, чрезвычайно полезный для Python разработчиков. Выпуски длятся 60 минут.



Для тех кто слушает сидя за компьютером есть также подкасты в видео формате:



LOFTBLOG





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



uWebDesign





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



ITVDN





Видео курсы по программированию, у них есть свой канал youtube который регулярно пополняется видеоподкастами и вебинарами на общие ИТ темы, такие как например “карьера в ИТ” так и по технологиям: JS, HTML/CSS, C#, .Net, Python итд. В целом контент рассчитан на новичков и программистов среднего уровня.



Livecoding.tv





Это платформа для программистов где последние вещают в онлайне процесс разработки, уроки, вебинары и подкасты в том числе. Из интересных можно выделить вебинары по JS от Никселя и разговоры о вебе от EBoldarev. Также на сайте круглосуточно можно найти трансляции на всевозможные темы например: добавление новых возможностей в компилятор C# от программиста из Microsoft, онлайн лекции от Стивена Вольфрама и просто девушек программирующих на Python и Ruby :)



Надеюсь эта подборка будет вам полезной. Если в списках отсутсвует ваш любимый подкаст, упомяните его в комментарии.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308532/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Музыка, Mathematica и вычислительная вселенная: автоматическое создание музыки на основе клеточных автоматов

Среда, 24 Августа 2016 г. 17:03 (ссылка)



Перевод поста Стивена Вольфрама (Stephen Wolfram) "Music, Mathematica, and the Computational Universe" о замечательном ресурсе WolframTones, работа которого была недавно возобновлена на новой площадке Wolfram Cloud (сайт, созданный в 2005 г., был недоступен пару лет, так как использовал не поддерживаемые современными браузерами решения).

Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.



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



Хотя музыка обычно имеет определенную формальную структуру, что отмечали пифагорейцы ещё 2500 лет назад, по своей сути она весьма человечна: отражение чистого творчества, которое есть суть определяющая характеристика человеческих способностей.



Но что есть творчество? Это то, что было необходимо в течение всей биологической и культурной эволюции? И может ли оно также существовать в системах, которые не имеют ничего общего с людьми?



В своей работе над книгой Новый вид науки (A New Kind of Science) я исследовал вычислительную вселенную возможных программ и обнаружил, что даже очень простые программы могут показывать поразительно богатый и сложный характер, наравне, например, с тем, что можно встретить в природе. И, опираясь на разработанный принцип вычислительной эквивалентности, я пришел к убеждению, что не может быть ничего, что принципиально отличает наши человеческие способности от любых процессов, которые происходят в природе, или даже в очень простых программах.



Но что можно сказать о музыке? Некоторые люди, выступая против принципа вычислительной эквивалентности, в качестве аргумента использовали свою веру в то, что "не могут существовать простые программы, которые смогут произвести серьёзную музыку".



И мне стало любопытно: действительно ли музыка есть что-то особенное и исключительно человеческое? Или всё таки её можно прекрасно создавать автоматически, с помощью вычислений?



В 2003 году, после десятка лет моей затворнической работы над A New Kind of Science, мне постепенно переставали быть чужды мирские проблемы, и одна из них заключалась в том, что рингтон на моём сотовом был как у всех. Так что я подумал: если какая-то оригинальная индивидуализированная музыка на самом деле может создаваться автоматически, то можно было бы просто поменять всем мелодии на мобильном, и каждый бы имел свою собственную.



Спустя некоторое время мы решили поэкспериментировать с возможностями создания музыки с помощью программ.



Получилась долгая история попыток создания музыки по правилам. Большинство полученного производило впечатление слишком "роботского" или случайного. Но то, к чему я пришёл в A New Kind of Science, казалось, давало нам новые возможности, ведь там было убедительно показано, что даже с правилами простых программ можно создавать такие сложные и живые вещи, которые мы наблюдаем в природе и которыми мы восхищаемся.



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



Факт в том, что за логикой в музыке всегда стоит какая-то простая программа. Но ключевым моментом A New Kind of Science является то, что основная программа может быть простой, однако производить богатую и сложную картину.



Но будет ли в этом эстетика? Что касается визуальной части, то мне уже давно было известно, что клеточные автоматы могут производить нечто весьма занятное и интересное. А с учётом того, что мы знали о клеточных автоматах, это не было особо удивительно. Потому что я знал, что они могут уловить суть многих процессов в природе. И поскольку мы находим природу эстетичной, то тоже самое должно быть справедливо и для клеточных автоматов.



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



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



Проходящие мимо нашего офиса люди, слыша воспроизводящуюся музыку, часто останавливались и спрашивали: "Что это за песню вы слушаете?" Мы делали музыку, которая была достаточно хороша для того, чтобы люди считали её сделанной людьми; можно сказать, что мы успешно прошли аналог теста Тьюринга для музыки.



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







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



Я рассматривал это как хорошую проверку принципа вычислительной эквивалентности. Как выразился один исследователь: "Стоит услышать музыку, производимую простыми программами, как они начинают выглядеть гораздо более похожими на нас".



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



image

(Прослушать аудио, соответствующее данному клеточному автомату)



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







Сайт WolframTones был запущен 16 сентября 2005 года. И вот, с тех пор он есть в интернете и с помощью Mathematica создаёт музыку. Должен признаться, что я некоторое время не смотрел его логи. Однако заглянув туда сейчас, я обнаружил, что он использовался десятки миллионов раз для создания десятков миллионов музыкальных композиций.



image

(Прослушать аудио, соответствующее данному клеточному автомату)



По меркам, к примеру, использования Wolfram|Alpha — это ничто. Но для музыкальных композиций это огромная цифра. Itunes в настоящее время содержит около 14 миллионов музыкальных композиций и представляет собой большинство того, что когда-либо было выпущено.  Но всего за несколько лет WolframTones создал большее количество композиций. Используя лишь вычисления, он в некотором смысле превзошёл наш вид в создании музыкальной продукции, в одиночку создав больше оригинальной музыки, чем за всё время до него.



Для того, чтобы результат выдавался мгновенно, сайт кодирует музыку в MIDI (то, что Mathematica теперь поддерживает напрямую в символьном виде). Было создано множество композиций WolframTones в MP3 формате. Полным перераспределением ролей можно назвать случай, когда я несколько лет назад ходил на концерт, где люди играли на скрипках фрагмент, полностью созданный с помощью WolframTones.



Могут ли простые программы полностью создать целую симфонию? Композиции в WolframTones ведают нам некоторые истории из вычислительного мира, которые имеют продолжительность, пожалуй, не более минуты. Судя по моему опыту, для того, чтобы создать больший фрагмент — тот, что поведает нам какую-то более длинную историю — нам потребуются структуры более высокого уровня. Однако у нас нет каких-то препятствий в создании простой программы, которая бы обеспечила подобную структуру. Главенствующая история может быть абсолютно полной, как и многие другие истории, что звучат в нашем мире музыкой законов природы.



Однако как много можно получить из столь малого? Как выглядит максимально короткая программа, создающая какой-то интересный музыкальный фрагмент?



Очень легко начать создавать программы в Mathematica:



Sound[
Map[
Function[
SoundNote[DeleteCases[3 * Range[21] * Reverse[#], 0] - 24,
0.1
]
],
Transpose @ CellularAutomaton[90, {{1}, 0}, 20]
]
]






(Прослушать аудио, соответствующее данному клеточному автомату)



Sound[
Map[Function[SoundNote[#, 1 / 6, "Warm"]],
Map[Pick[{0, 5, 9, 12, 16, 21}, #, 1] &,
CellularAutomaton[30,
{{1, 0, 0, 0, 0, 0}, 0},
13,
{13, 5}
]
]
]
]






(Прослушать аудио, соответствующее данному клеточному автомату)



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



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



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



Могут ли быть для нас поистине ценны автоматически созданные вещи, такие как музыка или что бы то ни было? Или нам всегда нужна история, связывающая то, что мы видим, со всем телом человеческой культуры? Возвращаясь к ранее сказанному — наше понимание природы ясно даёт понять, что нет никакой необходимости в человеческой истории. Вместо этого необходимой представляется связь с определенной всеобъемлющей логикой, которая, по сути, является именно тем, что обеспечивает концепция вычислительной вселенной.



Когда я смотрю на Wolfram|Alpha, меня захватывает радость от осознания того, как много человеческих знаний можно запечатлеть и сделать их вычислимыми. Новый рубеж — запечатлеть не только знания, но и творчество. Чтобы иметь возможность, например, добиваясь некоторой цели, понять творческий путь её достижения. Музыка есть суть плод чистого творчества, и то, что мы узнали, как предполагает принцип вычислительной эквивалентности, что даже в этой области, такие вещи, как WolframTones, удивительно хороши в получении творчески насыщенного результата.



Мы хотим воплотить более высокий уровень автоматизации, тем самым резко расширив творческие возможности, что, без сомнения, добавит множество новых увлекательных возможностей.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308428/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Новый курс на платформе Stepic: «Углубленное программирование на С/С++»

Среда, 24 Августа 2016 г. 16:45 (ссылка)





Мы продолжаем запускать курсы на платформе Stepic. И сегодня делимся с вами очередной новостью: 23 августа был запущен курс по углубленному программированию на языках C/C++. Продолжительность курса чуть больше двух месяцев. Это прекрасная возможность расширить знания и получить новый опыт в условиях, когда на очные занятия просто нет времени.



В основу как лекционной, так и практической части курса положены программы Технопарка и Техносферы — наших образовательных проектов, организованных совместно с МГТУ им. Н.Э. Баумана и МГУ им. М.В. Ломоносова. Обе программы успешно реализуются в очном формате уже несколько лет, а их выпускниками стали более 300 студентов. Все эти годы основной акцент в обучении делается на программной архитектуре, а также вопросах надежности, безопасности и переносимости исходного кода.



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



Однако основной «фишкой» курса, конечно, являются не задачи. Каждому участнику курса предстоит самостоятельно разработать простой — до 3000–5000 строк кода — проект на языке C++. Предметная область разработки, как и стек применяемых технологий специально не оговариваются: все творческие решения в рамках курса принимаются теми, кто его изучает. В ходе реализации поставленных задач участники могут использовать любые фреймворки или библиотеки, а результатом работы могут становиться не только традиционные мобильные или настольные приложения, но и решения для носимой электроники или серверные части web-сайтов.



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



Модули курса сгруппированы в 10 уроков, не считая приветствия и заключения. В ходе каждого из уроков участникам предстоит отвечать на вопросы текущего контроля знаний. Для этого в каждый урок введены 5 вопросов с выбором одного или нескольких вариантов ответа. Средний объем видеоматериалов каждого урока составляет около 100 минут.



Преподаватель курса — Алексей Петров, эксперт-практик в области информационного и программного обеспечения автоматизированных систем и языков программирования высокого уровня.



Регистрация на курс доступна по ссылке.

Original source: habrahabr.ru.

https://habrahabr.ru/post/308406/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Ember: Декларативная шаблонизация c компонируемыми хелперами

Вторник, 24 Августа 2016 г. 02:25 (ссылка)

Ранее, я упоминала, что помощники (Helper) Ember'а были введены в версии 1.13. На мой взгляд, помощники одни из самых полезных, но не часто обсуждаемых, функций Ember.



В моей лекции Idiomatic Ember на EmberConf 2016, я в деталях рассказала о хелперах, показывая, как они могут быть использованы для подключения и существенного расширения функционала Handlebars.

Они могут использоваться для декларативной шаблонизации — стиля шаблонизации использующего компонируемые действия (composing actions), и предоставляя шаблонам больше ответственности в отношении презентационный логики.



Вместе с коллегой Marten Schilstra, из DockYard, мы создали аддон ember-composable-helpers. Это пакет декларативных помощников, и с его помощью можно уменьшить количество шаблонного кода в Вашем приложении. Вы можете установить его так:



ember install ember-composable-helpers


Один из моих любимых помощников в аддоне — pipe (и его closure версия, pipe-action). Он позволяет декларативно составлять действия в шаблоне, вместо создания множества вариантов в компоненте:



{{perform-calculation
add=(action "add")
subtract=(action "subtract")
multiply=(action "multiply")
square=(action "square")
}}


{{! perform-calculation/template.hbs }}




Помощник pipe был вдохновлён оператором pipe Elixir'а (|>), который позволяет написать следующее:



A(B(C(D(E), "F"), "G"), "H")


Как цепочка преобразователей:



E
|> D()
|> C("F")
|> B("G")
|> A("H")


Используя pipe оператор, можно естественным образом выразить как E передаётся функции D, затем полученное значение передаётся C в качестве первого аргумента, и так далее. Я думаю, мы можем согласиться, что pipe версия намного легче для чтения!



Если бы Вы только знали мощь хелперов



Вы можете подумать, что помощник это примитивная KeyWord конструкция, использующая Ember и HTMLBars для расширения выражений, предоставленных Handlebars.

На самом базовом уровне, Handlebars отвечает за компиляцию hbs шаблонов в HTML:



{{myText}}



Hello world!



Ember и HTMLBars строится поверх этого, добавляя полезные выражения вроде action, mut, get, и hash. На самом деле, все знакомые хелперы, которые вы используете (от each до component) являются частью HTMLBars!



Ember Helpers работают на более высоком уровне, чем HTMLBars helpers, и могут быть использованы для создания новых выражений в Ember, позволяя эффективно расширить шаблонизацию с собственным поведением.



Всё зависит от обстоятельств



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



Для примера, в Elixir, макросы могут быть использованы для расширения языка, но не рекомендуется для реального использования. Это было закреплено в отличной книге Chris McCord Метапрограммирование на Elixir – "Правило 1: Не используйте макросы".



К счастью, помощники не настолько мощные как макросы Elixir, и играют важную роль в модели программирования Ember. В отличии от макросов, которые позволяют достучаться до AST, использование Ember помощника для расширения презентационной логики приемлемо пока мы не злоупотребляем этим, и это та особенность, где опыт вступает в игру. Так что используйте хелперы с умом.



Уберите прочь Вашу логику с моего газона



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



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



{{#unless (or (and (gte value 0) (lt value 0.0001))
(and (lt value 0) (not allowNegativeResults)))}}
...
{{/unless}}


Вместо этого используйте вычисляемые свойства (computed property).



В то же время, сохранять свои шаблоны на 100% свободными от логики очень тяжело – Вы, вероятнее всего уже используете логические помощники вроде if/else или unless. Можно легко упустить из виду тот факт, что количество логики в шаблоне строго не определено.



Назад в будущее



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



Например, Вы могли бы написать что-то подобное в вашем приложении:



import Ember from 'ember';

const {
Component,
computed: { filterBy, setDiff },
set
} = Ember;

export default Component.extend({
activeEmployees: filterBy('employees', 'isActive'),
inactiveEmployees: setDiff('employees', 'activeEmployees')
});


Довольно распространённая практика, иметь "компонент-посредник" для использования в других компонентах. С помощью ember-composable-helpers можно писать такие конструкции непосредственно в шаблоне, где всё абсолютно понятно:



Active Employees


{{#each (filter-by "isActive" engineers) as |employee|}}
{{employee.name}} is active!
{{/each}}

Inactive Employees


{{#each (reject-by "isActive" engineers) as |employee|}}
{{employee.name}} is inactive!
{{/each}}


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



С учетом выше сказанного, помните, не слишком увлекайтесь глубокой вложенностью!



Лучшее решение



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



Если Вы можете что-то сделать, не значит, что вы должны.

Хорошо написанный уровень представления(view layer) означает, что шаблоны должны быть декларативными (всё совершенно очевидно), насколько это возможно, а не то, что мы должны избегать логики вообще.

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



Если Вы хотите увидеть, как аддон используется, Katherin Siracusa написала отличную статью о том, как она использует ember-composable-helpers в AlphaSights:



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

Вы также можете принять участие в обсуждении на нашем Slack канале #e-composable-helpers.



Как всегда, спасибо за внимание!


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308326/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

А вот про нейронные сети, ИИ и т.д. [Опрос]

Вторник, 23 Августа 2016 г. 20:43 (ссылка)

На просторах интернета часто доводилось видеть мнения, что де "нейросеть — панацея от всего и вся", т.е. например "натравите нейросеть — и все, профит" или еще брутальней "скоро создадут ИИ на базе нейронной сети, которая сможет заменить даже программистов / администраторов / аналитиков и т.д.".

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



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

Т.е. я думаю, что в состоянии озвучить удаленность от реалий вышеприведенных высказываний.



Написать статью (и опрос) хотел уже довольно давно, но все как-то руки не доходили. А после очередного вопроса-предложения по е-майлу "натравите же нейронную сеть" на проблему из моей прошлой статьи "Мониторинг лог-журналов: Такой уязвимый лог...", все-таки понял — нет — надо писать.



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

Т.е. чтобы можно было ткнуть носом в статью очередного такого "все-лучше-всех-знающего" от интернета...



Хотя вдруг это я таки нещадно отстал от жизни...



Итак, для начала озвучим про или скорее контра использования нейронных сетей, что касается ее "интеллекта":




  • нейросеть "программируют", чтобы решать узконаправленные задачи, т.е. сеть распутывает только строго-определенные, семантически значимые для нее признаки;

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

  • данные из обучающей выборки, на которых собственно сеть обучается, должны быть:


    • репрезентативны (должны иллюстрировать истинное положение вещей в предметной области);

    • непротиворечивы (противоречивые данные приведут к плохому качеству обучения сети);

    • преобразованы к виду который можно отправить входным нейронам (т.е. должны быть как минимум первично обработаны другими алгоритмами)


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

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



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

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



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



Кроме, того нередко результат работы такого "алгоритма" есть вероятностная оценка (или группа их).

Что я хочу этим сказать. Ну возьмем к примеру лог-строчку из вышеупомянутого поста:



Aug 18 08:04:51 srv sshd[2131]: Failed password for invalid user test from 1.2.3.4 port 46589 ssh2 from 4.3.2.1 port 58946 ssh2


Ну оценит она это как "неавторизованная попытка с хоста 1.2.3.4 с вероятностью 99%", если она обучалась на миллионах строк, где после первого " from " всегда стоит плохой адрес (и страшно ошибется). Или в лучшем случае — пропустит ее как "мусорную" строку или найдет там оба адреса (что как минимум должно быть предусмотрено в самом flow ее создателем).



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



Как заставить ее "думать" как человек (т.е. начать как минимум сомневаться в том что видим) и главное принять в итоге правильное решение — это как раз очень сложная задача, которую пока решает разработчик (и нередко алгоритмически, вне или в обвязке нейросети) в каждом конкретном случае.

И это, как мне думается, еще очень и очень надолго.



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



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



Если же вы считаете, что создали уже что-то такое мега-умное, у меня для вас есть новости:




  • вы уже безработный

  • это вам уже не страшно, ибо вы еще и мультимиллиардер, т.е. уже сейчас можете смело брать кредит, идти покупать новую Теслу, уютный домик на Бора-Бора и т.п.

  • вас ненавидит лучшая часть человечества (другими словами вы выбрали себе врагами миллионы умнейших и образованнейших людей планеты)

  • скайнет уже близко (и скоро нас всех поработит)

  • за вами вероятно уже выехали (поэтому продумайте таки вариант с Бора-Бора)



Теперь собственно к опросам.



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




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

  • для теоретиков, т.е. людей, разбирающихся в теории, как это работает (но ни разу не использовавших это в бою)

  • предположения: для всех остальных (ну дайте уже кликнуть где-нибудь).



Огромнейшая просьба, не отсвечивать в опросах другой целевой аудитории (жмем "Воздержаться" после того как ответили в опросах у себя)...



Итак, поехали!





[Для профессионалов] Насколько «умны» современные нейронные сети и системы на их базе (что они для вас)


































































































Проголосовало 48 человек. Воздержалось 106 человек.





[Для профессионалов] Смогут ли ИИ в обозримом будующем заменить разработчика


























































Проголосовало 58 человек. Воздержалось 96 человек.





[Для теоретиков] Насколько «умны» современные нейронные сети и системы на их базе (что они для вас)


































































































Проголосовал 41 человек. Воздержалось 89 человек.





[Для теоретиков] Смогут ли ИИ в обозримом будующем заменить разработчика


























































Проголосовало 48 человек. Воздержалось 90 человек.





[Как вы предполагаете] Насколько «умны» современные нейронные сети и системы на их базе (что они для вас)


































































































Проголосовало 57 человек. Воздержалось 76 человек.





[Как вы предполагаете] Смогут ли ИИ в обозримом будующем заменить разработчика


























































Проголосовало 67 человек. Воздержалось 73 человека.





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


Original source: habrahabr.ru.

https://habrahabr.ru/post/308356/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Kotlin: без Best Practices и жизнь не та. Часть 1

Вторник, 23 Августа 2016 г. 11:08 (ссылка)

Привет, Хабр! Данная статья о наболевших проблемах при программировании на Kotlin. В частности, затрону несколько тем, вызывающих больше всего неоднозначности – использование it в лямбда-выражениях, злоупотребление функциями из файла Standard.kt и краткость написания vs. читаемость кода.



Предыстория



Я начал смотреть на Kotlin около года назад (начиная с Milestone 12) и активно применял его для написания своих Android-приложений. После двух лет написания Android-приложений на языке Java писать на Kotlin было глотком свежего воздуха — код был намного компактнее (никаких тебе анонимных классов, появились функциональные фичи), а сам язык намного выразительнее (extension-функции, лямбда-функции) и безопаснее (null safety).



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



Спустя какое-то время я начал замечать, что в некоторых случаях нужно бить себя по рукам и писать более длинный, но понятный код, нежели краткий и менее понятный. Пример:



// Намного лучше читается, когда выход из функции следует сразу за единственным Safe-call ("?."), после чего идет получение имени отдельной строчкой
val user = response?.user ?: return
val name = user.name.toLowerCase()

// Хуже читается, когда сразу несколько разных действий совмещено на одной строчке
val name = response?.user?.name.toLowerCase() ?: return


Так как я был единственным программистом, быстро понял эту закономерность и неявно выработал для себя правило предпочитать читаемость кода его краткости. Всё бы было ничего, пока мы не взяли на стажировку начинающего Android-программиста. Как я и ожидал, после прочтения официальной документации по языку он быстро освоил Kotlin, имея за плечами опыт программирования на Java, но потом стали происходить странные вещи: каждое code review вызывало между нами получасовые (а иногда и часовые) дискуссии на тему того, какие конструкции языка лучше использовать в тех или иных ситуациях. Иными словами, мы начали вырабатывать стиль программирования на Kotlin в нашей компании. Я считаю, что эти дискуссии возникали по той причине, что в документации, являющейся входной точкой в мир Kotlin, не приведено тех самых Best Practices, а именно когда лучше НЕ использовать данные фичи и что лучше использовать вместо этого. Именно поэтому я и решил написать данную статью.



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



Проблемы в языке



«It» сallback hell



Данная проблема заключается в том, что в Kotlin разрешено не именовать единственный параметр функции обратного вызова. Он по умолчанию будет иметь имя «it». Пример:



 /** Интерфейс с методом call, который принимает один параметр и ничего не возвращает */
interface Callback {
fun call(parameter: Any?)
}

fun execute(callback: Callback) {
...
callback(parameter)
...
}

/** Пример вызова. Kotlin позволяет писать как execute { ... }, так и execute({ ... }), выберем более краткий вариант */
execute {
if (it is String) { // Доступ к parameter через переменную it, проверка что он имеет тип String
....
}
....
}


Однако когда мы имеем несколько вложенных функций, может возникнуть путаница:



execute {
execute {
execute {
if (it is String) { // it относится к последнему по вложенности вызову execute
....
}
....
}
}
}

execute {
execute {
execute { parameter ->
if (it is String) { // здесь it относится уже к предпоследнему по вложенности вызову execute, так как параметр последнего имеет другое имя
....
}
....
}
}
}


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



executeRequest { // здесь it - это экземпляр класса Response
if (it.body() == null) return
executeDB { // здесь it - это экземпляр класса DatabaseHelper
it.update(user)
executeInBackgroud { // здесь it - это экземпляр класса Thread
if (it.wait()) ...
....
}
}
}


Здесь приведена дискуссия на тему читаемости кода, использующего it. Мое мнение — it сильно помогает сокращать код и повышает его понятность для простых функций, но как только мы имеем дело со вложенной функцией обратного вызова, лучше давать имена параметрам обеих функций:



 // Простая функция
executeInBackgroud {
if (it.wait()) ...
....
}

// вложенная функция
executeRequest { response ->
if (response.body() == null) return
executeDB { dbHelper ->
dbHelper.update(user)
...
}
}


Злоупотребление функциями из файла Standard.kt



Для тех кто не знает, в файле Standard.kt находится множество полезных функций. Здесь приведено подробное описание для чего нужна каждая из них.



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



Первый пример — функция let, которая по сути выполняет 2 задачи: позволяет вызвать код, если какое-то значение не равно null и перекладывает это значение в переменную it:



response?.user?.let {
val name = it.name // в it теперь лежит объект user
}


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



val user = response?.user ?: return
val name = user.name


В третьих, let добавляет лишний уровень отступа, что ухудшает читаемость кода. Почитать по поводу данной функции можно здесь, здесь и здесь. Моё мнение — данная функция вообще не нужна в языке, единственный плюс от нее — помощь с null safety. Однако даже этот плюс можно решить другими более изящными и понятными способами (предварительная проверка на null при помощи ?: или просто if).



Что касается остальных функций, то они должны применятся крайне редко и осторожно. Возьмем, к примеру, with. Она позволяет не указывать каждый раз объект, на котором нужно вызвать функцию:



with(dbHelper) {
update(user)
delete(comment)
}

// вышеприведенный код эквивалентен следующему:
dbHelper.update(user)
dbHelper.delete(comment)


Проблема начинается там, где данные вызовы перемешаны с другим кодом, не относящимся к объекту dbHelper:



with(dbHelper) {
val user = query(user.id)
user.name = name
user.address = getAddress() // getAddress() не относится к объекту dbHelper
....
update(user)
val comment = getLatestComment() // getLatestComment() также не относится к объекту dbHelper
....
delete(comment)
}


В данном случае приходится постоянно следить за тем, кому же на самом деле принадлежит та или иная функция, что значительно снижает читаемость. Пример со вложенным использованием with приводить не буду, и так понятно, какой спагетти-код получится в итоге.



О других наболевших вещах напишу в следующей статье, потому что это уже успела разрастись.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308312/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Parallels Toolbox поможет скачать ролик с YouTube, выключить микрофон, записать видео и многое другое

Вторник, 23 Августа 2016 г. 11:01 (ссылка)

image

Совсем недавно мы представили Parallels Desktop 12 для Mac. Вместе с нашей обновленной утилитой Мас-пользователи получили набор инструментов Parallels Toolbox. В этой статье мы расскажем об основных его функциях и постараемся ответить на ваши вопросы в комментариях.



Идея создания Parallels Toolbox заключалась в том, чтобы дать пользователю Mac набор наиболее востребованных инструментов, которых ему не хватает в повседневной жизни в стандартной комплектации операционной системы и офисного пакета. Тех, которые ему при установке или переустановке системы зачастую приходится скачивать отдельно с десятков разных сайтов. Мы понимали, что для того, чтобы все это имело смысл, инструмент всегда должен быть виден и доступен на расстоянии одного щелчка мыши или тачпада — и при этом все утилиты должны быть унифицированы, т.е. настолько похожи, чтобы опыт пользователя мог быть перенесен с одного инструмента на другой. Мы также понимали, что такой набор должен быть универсальным и расширяемым.



Поэтому мы сделали три вещи. Мы изучили наиболее популярные функции, которые либо были слишком сложно организованы в операционных система Apple (например, сложная клавиатурная комбинация, которую невозможно запомнить), либо требовали дополнительной установки разнообразных утилит. Также мы проанализировали обращения пользователей в нашу службу поддержки. Нередко люди звонят к нам с вопросами не про Parallels Desktop для Mac, а интересуются базовыми функциями техники Apple. Далее мы отобрали несколько десятков самых «топовых» запросов — таких, как создание снимков с экрана, включение и отключение автоматического «засыпания» устройства, очистка рабочего стола — и разработали собственные инструменты для каждого из них. После чего, мы еще раз посмотрели на все эти приложения и унифицировали их интерфейс так, чтобы получился действительно единый набор инструментов, который мы со временем сможем расширять, добавляя для пользователя ценность.



Скелет Toolbox’а

Общий принцип интерфейса Toolbox — кликовая доступность. Все инструменты унифицированы в меню из двенадцати схожих по графическому оформлению иконок. Некоторые из них содержат расширенную функциональность. Например, видеоскрин в подменю позволяет не только захватывать выделенную область, но и экран целиком. При наведении на иконки всплывают подсказки с описанием функций. В верхней части Parallels Toolbox располагается библиотека активированных инструментов. Также иконки могут быть перенесены в Apple Dock. На все иконки распространяется поддержка перетаскивания файлов мышью (Drag & Drop). Стоит добавить, что любой из активированных вами инструментов действует до окончания суток, после чего его нужно активировать заново. Это сделано на тот случай, если вы задействовали какой-либо из инструментов и забыли его отключить.





Архивация

Mac OS умеет работать только с ZIP-архивами и не умеет защищать их паролями. Parallels Toolbox работает со всеми популярными форматами архивов, умеет защищать архивы паролем и распаковывать защищенные архивы.





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



Снимок с экрана

Возможность создания снимков с экрана в Mac OS существует, но она реализована слишком сложной комбинацией клавиш — нужно нажать Command–Shift–3, а чтобы выбрать часть экрана — Command–Shift–4. Для скриншота окна, нужно нажать Command–Shift–4, затем пробел и кликнуть нужное окно. Поэтому мы решили создать инструмент, предоставляющий пользователю ровно три возможности — значок Capture Area для создания снимка участка экрана, Capture Screen для создания снимка всего экрана, Capture Window для создания снимка отдельного окна.





Все, что нужно сделать пользователю — это щелкнуть соответствующий значок. Все инструменты Parallels ToolBox можно запускать из Spotlight — а если разместить самые необходимые значки в Apple Dock, то операции станут максимально удобными, чего мы и добивались.



Загрузка видео

Один из самых популярных инструментов Parallels ToolBox — Download Video для загрузки видео из веб-ресурсов, таких как YouTube, Facebook и других. Чтобы загрузить видео, нужно скопировать ссылку на это видео и щелкнуть значок Download Video. Утилита предложит скачать видео по ссылке, а когда она это сделает, пользователь получит готовое видео в формате MPEG4, которое можно проиграть на всех моделях устройств Apple. Разумеется, пользователь при этом должен помнить, что он сам должен следить за лицензионной чистотой материалов, которые он загружает из Интернета — как, впрочем, и всегда.



Блокировка микрофона

Помните фото Цукерберга облетевшее интернет? Там, где он запечатлен с заклеенными камерой и микрофоном рабочего ноутбука. Кликнув на Mute Microphone на панели Parallels Toolbox Марк мог бы избавить себя от забот. Активируйте соответствующую иконку, и микрофон вашего ноубтука будет заблокирован, а если некое приложение попробует его разблокировать, пользователь немедленно получит системное сообщение: «Внимание, такое-то приложение хочет разблокировать микрофон. Ты согласен?».





Блокировать микрофон устройства приходится не только на случай приступов паранойи — хотя наш инструмент годится и для этого. Более распространенный сценарий — когда во время разговора с использованием одного из приложений для голосовой связи (а это может быть встроенное приложение Мака FaceTime, Skype, Cisco Webex, Citrix GoToMeeting или любая другая популярная программа) нужно оперативно выключить микрофон. Для этого придется переключиться в окно соответствующего приложения (причем не факт, что пользователь всегда помнит, какое именно приложение он использует в данный момент) и найти там кнопку выключения микрофона — либо воспользоваться значком Mute Microphone, находящимся в Apple Dock, что гораздо удобнее. К сожалению, заблокировать видеокамеру оказалось не так просто. В ближайших обновлениях мы справимся и с этой задачей.



Конвертирование видео

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

Существующие приложения для конвертирования видео, как правило, сложны в использовании, они имеют множество настроек и конфигураций, которые ничего не говорят обычному пользователю. Мы же предлагаем простой инструмент Convert Video с минимумом настроек, который позволяет выбрать разрешение 1280x720 или 1920x1080, указать файл для конвертирования — и все. Кроме того, Convert Video может добавить полученный видеофайл в iTunes, чтобы «раздать» его на все совместимые устройства, принадлежащие пользователю. Таким образом мы создали простой инструмент для обычных пользователей, которые не разбираются в настройках видео и просто хотят смотреть фильмы.

Учитывая, что на все приложения Parallels Toolbox распространяется поддержка перетаскивания файлов мышью, пользователь перетаскивает видеофайл на значок Convert Video — и он автоматически конвертируется с параметрами по умолчанию. Можно создать два экземпляра Convert Video, один будет конвертировать видео в формат 1280x720, другой — в 1920x1080. Полученный файл будет иметь совместимый формат H.264 с соответствующим устройству разрешением, с частотой 30 кадров в секунду и стереозвуком 48 кГц стерео, 160 кбит в секунду.



Запись видео с экрана

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

Наш инструмент Record Video состоит на самом деле из трех инструментов — для записи всего экрана, для записи выбранной части экрана и для записи выбранного окна. Работает все очень просто — пользователь щелкает мышью значок инструмента, выбирает область записи, включает запись — и выполняет на компьютере те действия, которые необходимо записать. Когда все сделано, надо еще раз щелкнуть значок приложения, чтобы остановить запись. Видео записывается в формате MOV, которое может быть воспроизведено на любом компьютере, на котором установлено приложение QuickTime — а QuickTime, как известно, входит в iTunes. Это значит, что видео сможет проиграть любой пользователь любого устройства Apple, а также все те, кто установил версию QuickTime для Windows.





Не спать

Некоторые инструменты Parallels ToolBox вообще не имеют никакого пользовательского интерфейса. Например, все, что делает инструмент «Не спать» — блокирует автоматическое включение хранителя экрана и не даёт Маку «засыпать». Компьютер может быть настроен на автоматическое «засыпание» после 10 минут отсутствия активности, но при этом он будет засыпать, например, и в том случае, если на экране более 10 минут отображается же слайд презентации. Самый легкий способ решения этой проблемы, который избавляет пользователя от необходимости постоянно менять настройки засыпания устройства — инструмент Parallels ToolBox «Не спать». Пользователь щелкает значок Do Not Sleep и компьютер не будет засыпать, пока значок не щелкнут его еще раз. Если пользователь забудет это сделать — не беда, в полночь этот режим отключится.



Не беспокоить

Аналогичный инструмент без пользовательского интерфейса — «Не беспокоить». Когда его активируют, на устройстве отключаются любые всплывающие сообщения и анимации приложений в Apple Dock.

Для чего это нужно? Например, пока идет презентация, любые уведомления об активностях программы электронной почты или Skype попросту неуместны. Щелкните значок Do Not Disturb и не отвлекаетесь, пока не закончите текущую задачу. Как и режим «Не спать», этот режим отключается в полночь — на тот случай, если пользователь сам забудет его отключить.



Блокировка экрана

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



Уборка

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



Тайм-менеджмент

Как ни странно, мы привыкли к тому, что будильники, секундомеры и таймеры есть на наших мобильных гаджетах: на телефонах, даже на часах, а на компьютерах Mac их нет. И все же иногда удобнее и быстрее воспользоваться подобными функциями на компьютере, поэтому мы включили их в Parallels Toolbox. Эти четыре инструмента — будильник, таймер, секундомер и утилита отсчета дней к определенной дате.





Задачи, которые выполняют будильник, таймер и секундомер, понятны, подробно описывать мы их не будем, но у этих инструментов есть важная особенность — если компьютер перезапустить, отсчет времени продолжается.

Отдельно расскажем об инструменте Date Countdown. Пользователи часто хотят знать, сколько дней осталось до определенной даты — до даты окончания проекта, до дня рождения, до дня свадьбы и т.д. И мы реализовали ее — нужно просто запустить Date Countdown и указать целевую дату. Приложение начинает отсчитывать количество календарных дней, оставшееся до этой даты, и показывает его в соответствующем значке — в Apple Dock, как уже отмечалось, можно создать столько значков Parallels Toolbox, сколько нужно. Когда дата достигнута, система выдает соответствующее уведомление. Не исключено, что в следующем выпуске мы добавим такую опцию, как подсчет не только календарных, но и рабочих дней, с учетом национальных праздников и т.п.



Как купить Parallels Toolbox

Для пользователей обновленной утилиты Parallels Desktop 12 для Mac набор инструментов Parallels Toolbox доступен бесплатно. Также его можно скачать отдельно. Цена за подписку на год составляет 490 рублей. В эту цену входят также новые инструменты, которые мы будем добавлять в набор Parallels Toolbox в течение года.

На данный момент продукт доступен только на сайте Parallels. В перспективе он появится и в Mac App Store. В настоящее время для нас это не самая приоритетная задача — по той простой причине, что Mac AppStore, в отличие от iOS App Store, не так уж популярен среди пользователей, и многие разработчики вообще не размещают свои приложения в Mac App Store.





В первой версии Parallels Toolbox реализовано 20 выбранных нами наиболее популярных инструментов. В течение следующих нескольких месяцев пакет пополнится новыми функциями, так что оставайтесь с нами! Делитесь впечатлениями от Parallels Desktop 12 для Mac и Parallels Toolbox и задавайте вопросы в комментариях к этой статье.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308306/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Пишите меньше кода, блин

Вторник, 23 Августа 2016 г. 10:35 (ссылка)

Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.



А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).



Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).



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



В стремлении к уменьшению мне больше всего нравится вот что: в конце остается только то, что реально нужно, только то, что по-настоящему требуется пользователю. Огромная фотка какого-то чувака, пьющего латте? Выкинуть. Кнопки социальных сетей, которые подсасывают кучу левого кода и ломают дизайн страницы? Пинок под зад им. Эта хреновина на JavaScript, которая перехватывает правый клик и показывает кастомное модальное окно? Выставить на мороз!



Речь идет не только про подключение штук, которые ломают интерфейс. То, как вы пишете свой собственный код, тоже играет большую роль в стремлении к уменьшению кода. Вот несколько советов и идей. Я писал о них ранее, но в контексте удобства и отзывчивого дизайна. Просто так получается, что гибкий, удобный веб требует меньше контроля с нашей стороны и его сложнее сломать.



WAI-ARIA



Во-первых, WAI-ARIA != web accessibility. Это просто инструмент для улучшения совместимости с некоторыми вспомогательными технологиями вроде экранного диктора. Поэтому первое правило ARIA — это не использовать его, если не требуется.



LOL, нет:



Subheading


Да:



Subheading



Преимущество использования нативных элементов в том, что зачастую не нужно будет кодировать собственное поведение. Следующая реализация чекбокса не только слишком многословная, но также зависит от JavaScript, который контролирует изменение состояния и переопределяет стандарт работы с атрибутами и методом GET. Кода больше, и он менее надежный. Красота!




My checkbox label


Стили? Не волнуйтесь, все под контролем. Если вообще нужны кастомные стили, конечно.






Сетка



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



Конечно, иногда хочется поставить какую-нибудь штуку рядом с другой штукой. Например, поисковую выдачу или еще что-то. Но зачем тянуть сюда тонну библиотек для сеток? Флексбокс умеет это буквально с двумя блоками определений.



.grid {
display: flex;
flex-flow: row wrap;
}

.grid > * {
flex-basis: 10em;
flex-grow: 1;
}


Теперь все будет растягиваться до примерно 10em в ширину. Количество колонок зависит от того, сколько ячеек размером примерно 10em поместится в viewport. Готово. Идем дальше. А, кстати, давайте еще обсудим такую штуку:



width: 57.98363527356473782736464546373337373737%;


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



Отступы



Мы знаем, как это делается. Задавайте отступ для всех элементов, используя универсальные селекторы. И переопределяйте когда нужно. Много не потребуется.



body * + * {
margin-top: 1.5rem;
}


Нет, универсальный селектор не ухудшит производительность. Это ересь.



Вид



Не нужен целый Angular или Meteor чтобы поделить простую страницу на "views". Views это просто куски страницы, которые видны в те моменты, когда не видны другие. Это можно сделать с CSS:



.view {
display: none;
}

.view:target {
display: block;
}


«Но одностраничные приложения запускают код при загрузке view!», — скажете вы. Я понимаю. Для этого существует событие onhashchange. Не нужно библиотек, и ваши ссылки будут нормальными, стандартными, их можно добавлять в закладки. Это клево. Об этом можно почитать больше, если интересно.



Размер шрифта



Тонкая настройка размера шрифта может сильно раздуть ваши блоки media. Поэтому нужно отдать это в руки CSS. Одна строчка кода.



font-size: calc(1em + 1vw);


Э-э-э… вот и все. Есть даже минимальный размер, так что не будет нечитаемых крохотных букв на мобильных устройствах.



10k Apart



Как я сказал, я не лучший в мире кодер. Я просто знаю несколько трюков. Но с небольшим количеством знаний можно сделать очень многое. В этом суть соревнования «10k Apart» — выяснить, чего можно добиться с 10kb или меньше. Есть большие призы. Я как судья не могу дождаться, когда возьмусь за изучение всех крутых заявок, идей и реализаций, которые мне хотелось бы придумать самому. А что придумаете вы?


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308308/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Node.js и JavaScript вместо ветхого веба

Вторник, 23 Августа 2016 г. 09:20 (ссылка)

Вступление



Эта статья про экспериментальный технологический стек общего назначения. Она не просто дублирует мой доклад на конференции ОдессаJS 2016, но содержит все то, что в доклад не поместилось из-за недостатка времени и исключительного масштаба темы. Я даже перезаписал доклад голосом по тексту статьи и это можно послушать, а не читать. С этой темой я уже выступил в Уханьском Университете (Китай), а в Киевском Политехническом Институте провел целую серию семинаров в 2015-2016 годах. Основная идея состоит в том, что проблемы фрагментации технологий могут быть решены, если спроектировать весь технологический стек, сконцентрировавшись на структурах данных, синтаксисе и протоколе взаимодействия компонентов. Большинство вопросов несовместимости, отпадет само собой. Пусть даже этот подход будет альтернативным и экспериментальным, но его задача будет выполнена, если он наметит путь и продемонстрирует принципиальную возможность создания простого и элегантного решения общего назначения. Эта идея является естественным продолжением подхода Node.js, когда мы сокращаем количество языков и технологий в системе, разрабатывая и клиент и сервер на JavaScript. Несмотря на экспериментальность, протокол JSTP уже используется в коммерческих продуктах, например, для интерактивного телевидения компанией SinceTV, где позволяет подключить одновременно десятки миллионов пользователей. Это решение получило приз за инновации в области телевидения на международном конкурсе Golden Panda Awards 2015 в Ченду (Китай). Есть внедрения в сфере управления серверными кластерами, готовятся решения для медицины, интерактивных игр, электронной торговли и услуг.







Слайды: http://www.slideshare.net/tshemsedinov/metarhia-nodejs-macht-frei

Аудио версия: https://soundcloud.com/timurshemsedinov/nodejs-macht-frei



Выступление



Добрый день, меня зовут Тимур Шемсединов, я архитектор SinceTV, автор Impress Application Server для Node.js, научный сотрудник НИИ Системных Технологий и преподаватель КПИ. Сегодняшняя тема не столько про ноду, а скорее про развитие той идеи, которая легла в основу ноды.



Каждый, кто разрабатывал приложения не только для веба, может легко сравнить стройность технологического стека, объемы возникающих проблем и, в конечном счете, скорость разработки, с аналогичными по сложности проектами для мобильных устройств или оконных приложений для десктопов, для суперкомьпьютеров или встраиваемой техники, программирование для серверов и промышленной автоматизации, обработки данных или другими отраслями применения программирования.



Каждый шаг в вебе — это борьба, каждая минута — боль, каждая строчка — компромисс или заплатка. В интернете множество статей о том, что хаос захлестнул ветхий веб и хорошие специалисты тратят недели на простейшие задачи, как то — подвинуть кнопочку на 3 пикселя вверх или поймать блуждающий баг в зоопарке браузеров. Например статья с Медиума «I’m a web developer and I’ve been stuck with the simplest app for the last 10 days» переведенная на Хабре «Я веб-разработчик и уже 10 дней не могу написать простейшее приложение».



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



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



Представьте, что мы откажемся от HTTP, HTML, CSS, DOM, URL, XMLHttpRequest, AJAX, JSON, JSONP, XML, REST, Server-Sent Events, CORS, Cookie, MIME, WebSocket, localStorage, indexedDB, WebSQL, и всего остального, кроме одной вещи, мы оставим JavaScript и сделаем из него абсолютно все, что необходимо для разработки приложений. На первый взгляд это может показаться странным, но дальше я покажу, как мы это сделаем. Это будет целостный технологический стек на одном лишь JavaScript и вам это понравится. Мы конечно будем привлекать другие технологии для создания среды исполнения приложений, но от разработчика приложений все эти внутренности будут скрыты.



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



Мы хотим разрабатывать прикладное программное обеспечение для информационных систем в таких сферах: бизнес, экономика, образование, медицина, корпоративные информационные системы и организационно-управленческие системы, электронная торговля, персональная и групповая коммуникация, социальные сети, игровые приложения, телевидение и другие средства массовой информации.



Эти системы должны быть:




  • распределенными (включающими в себя много клиентских терминальных устройств и много серверов),

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

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

  • безопасными (одновременно анонимными и обеспечивающими достаточный уровень идентификации и доверия для отдельных операций),

  • гибко изменяющимися (модифицирующими экраны, функции и структуры данных на лету, без переустановки и перезапуска).



При помощи каких технологий мы можем сегодня разрабатывать такие приложения, перечислим:




  • оконные и локально установленные приложения (для Linux, MacOS, Windows) с использованием AWT, SWING, WinForms, WPF, Qt и т.д.

  • мобильные приложения (iOS, Android, и другие)

  • веб-приложения, в том числе и адаптированные для мобильных версий браузеров

  • Progressive Web App (полноэкранные приложения запускаемые в скрытом браузере)

  • NW.js и Electron



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



Веб мог бы быть решением для кросплатформенности, но какой набор технологий мы имеем в ветхом вебе:



Начнем с HTTP. Думаю, ни для кого не секрет, что он блокирующий, т.е. через одно соединение, которое браузер установил, может быть одновременно отправлен только один запрос на сервер и соединение ждет, пока сервер ответит. Потому, что в HTTP нет нумерации запросов, просто обычной, примитивной, самой простой нумерации нет и открытое соединение ожидает. Ведь если послать второй запрос, то получив ответ, будет не ясно, это ответ на первый запрос или на второй. Не говоря уже про передачу ответа частями, которые смешались бы. Но при загрузке приложения нужно сделать много запросов и браузер устанавливает второе соединение для второго запроса, потом третье… В большинстве браузеров это число ограничено 6 одновременными соединениями, т.е. сделать больше параллельных запросов нельзя, ни для загрузки статики, ни для AJAX. Если конечно не соорудить костыль, создать множество поддоменов и разбрасывать запросы на поддомены, ведь ограничение на 6 соединений у браузера привязано именно к хосту. Но эти десятки и сотни соединений неэффективно используют сеть.



Вообще TCP предполагает надежную доставку и долгосрочное взаимодействие, но HTTP разрывает связь очень часто, он просто не умеет эффективно переиспользовать уже установленные соединения и постоянно их разрывает и создает новые. Есть конечно Keep Alive, но мало того, чтобы он был специфицирован, его должны поддерживать веб-сервер, браузер, и разработчики должны о нем знать, правильно формировать заголовки и обрабатывать их. Обычно чего-то не хватает, то админ без руки, то разработчики не слышали про такую возможность, да и браузеры имеют особенности, как оказалось, и Keep Alive работает очень не эффективно, из-за отхода от спецификации сервер часто не может договориться с браузером и соединение не переходит в Keep Alive режим. Я об этом уже делал доклад и писал статью год назад "Как исправить ошибку в Node.js и нечаянно поднять производительность в 2 раза" https://habrahabr.ru/post/264851/ Поведение HTTP можно проследить в средствах для разработчика, которые есть в браузере. Оптимизация в HTTP это отдельная задача, из коробки ее нет да и всем безразлично.



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



У HTTP очень много проблем, их пробовали решать при помощи Websocket, SSE, SPDY, HTTP/2, QUIC но все они зависят от бесчисленного множества вещей, которые достались в наследство от ветхого веба и ни одна из этих технологий не достигла ни приемлемых характеристик, ни широкой поддержки. Уплотнить уже имеющийся трафик, сделать мультиплексацию внутри другого транспорта можно, но структура трафика не изменится, это будут все те же HTML, AJAX, JSON, ведь задача стояла, починить транспорт так, чтобы ничего не сломалось и чрез него продолжали ходить все те же приложения. А вот не достигнута цель, все сложно, не внедряется это массово и прирост в скорости не очень ощутим при внедрении. Кардинально и комплексно ни кто не пробовал решить проблему.



Для игр, мессенджеров и других интерактивных приложений сейчас есть только один живой вариант — это Websocket, но этот слоеный пирог из протоколов достиг предела. IP пакетный, на его основе TCP потоковый с установлением долгих соединений, сверху HTTP — он опять пакетный с постоянным отключением и поверху Websocket — и он потоковый, с долгими соединениями. А еще все это через SSL может идти. И каждый слой добавляет свои заголовки и преобразовывает данные, особенно при переходе от пакетного к потоковому и от потокового к пакетному. Это похоже на издевательство, честное слово.



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



Пора признать, что HTTP, полон проблем и костылей, он спроектированный полуграмотными в ИТ физиками CERNа, которые полезли не в свою специальность, в прошлом веке для передачи статей, снабженных ссылками, и ни как не подходит для приложений, тем более для интерактивных приложений с интенсивным обменом данными.



HTML это конечно прекрасный язык для разметки страниц, но менее всего приспособленный для сложных пользовательских графических интерфейсов. Скорость работы DOM и отсутствие транзакционности в изменении интерфейсов приводят к залипанию веб-приложений. Сложно придумать что-то более избыточное и медленное для представления пользовательских интерфейсов в памяти и динамической модификации экранов. Это решается в Shadow DOM, React, Angular, Web components но проблем все еще больше, чем решений.



Еще немного про масштабирование. REST, который обещал всем прозрачное решение, вместо этого забрал возможность работать с состоянием, и не сделал обещанного. Мы имеем ситуацию, когда ни кто не использует REST, да ладно, мало кто понимает, что это, но все говорят, что у них REST API. URLы идентифицируют объекты или методы? PUT, PATCH и DELETE используются? Последовательность вызовов API не важна? У кого через REST работают платежи, корзина, чат, напоминания? В основном у всех AJAX API, которое так и нужно называть. А проблема с масштабирование как была, так и решается каждый раз заново.



Проблем слишком много для того, чтобы вдаваться дальше в подробности, давайте кратким списком теперь подытожим основные:




  • Платформы для прикладных программных систем фрагментированы

  • Архаичные веб технологии уже нас не удовлетворяют

  • Фреймворки и инструменты тотально нестабильны и несовместимы

  • Протоколы ветхого веба имеют большую избыточность и убивают производительность ваших серверов

  • Сплошные проблемы безопасности и заплатки



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



Что же нам нужно:




  • Среда исполнения приложений для серверов

  • Среда исполнения приложений для пользовательских компьютеров

  • Среда исполнения приложений для мобильных устройств

  • Межпроцессовое взаимодействие по принципам RPC и MQ с поддержкой интроспекции, потоков событий и потоковой передачи двоичных данных

  • Система управления базами данных с глобальным пространством адресации, распределенностью и шардингом из коробки

  • Новые соглашения по именованию и идентификации данных и пользователей



Это уже не сеть веб-страниц, а сеть приложений и баз данных.

И теперь я покажу, что это возможно. Не утверждаю, что нужно делать именно так, но принципиальную возможность на прототипе наша команда продемонстрирует.



Metarhia — это новый технологический стек, который:




  • экспериментальный (только для демонстрации нового подхода),

  • альтернативный (не должен заботиться о совместимости),

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



Теперь давайте ближе к JavaScript, у него же есть прекрасный синтаксис описания структур данных, включающий хеши, массивы, скалярные величины, функции и выражения. А нам нужен универсальный сетевой протокол, который бы соответствовал структурам данных языка и исключал бы излишнюю перепаковку данных. Нам нужен сквозной протокол и он же формат сериализации, один на весь стек технологий, в базе данных, в памяти клиента, в памяти сервера и при передаче между процессами. Так зачем же нам JSON, XML, YAML и прочие, если таким форматом может быть подмножество языка JavaScript. При этом мы не выдумываем ни какого стандарта, ни какой формальной граматики, у нас уже есть все. По большому счету, заготовки для парсеров уже реализованы на всех языках и платформах. Более того, если мы возьмем V8 и заставим его быть парсером сетевых пакетов, то получим статистическую оптимизацию, скрытые классы и на порядок более быстрый парсинг, чем JSON. Тесты производительности я опубликую позже, чтобы не перегружать этот, и так объемный, доклад.



Пусть протокол станет центральным стержнем, на который цепляются все компоненты системы. Но протокола мало, нам нужна среда запуска, как клиентская, так и серверная. Развивая идеи Node.js, мы хотим, чтобы не только язык, но и среда запуска была почти идентичной на сервере и на клиенте. Одинаковое API, которое дает возможность обращаться к функциям платформы, например к сети, файловой системе, устройствам ввода/вывода. Конечно же, это API не должно быть бесконтрольно доступным приложениям, а обязано иметь ограничения безопасности. Область памяти и файловая система должны быть виртуальными, замкнутыми песочницами, не имеющими сообщения с остальной средой запуска. Все библиотеки должны подгружаться не самими программами, а внедряться средой запуска как DI через инверсию управления (IOC). Права приложений должны быть контролируемы, но не должна происходить эскалация управления до пользователя, потому, что он не способен принять адекватного решения по правам доступа. Пользователь склонен или запрещать все, руководствуясь паранойей или разрешать все, руководствуясь беспечностью.



Еще нам нужна СУБД, которая будет хранить данные в том же формате JavaScript. Нам нужен язык описания моделей (или схем) данных. Нам нужен язык запросов к структурам данных. В качестве синтаксиса этих двух языков запросов мы можем взять тот же синтаксис JavaScript. И в конце концов нам нужен язык описания интерфейсов двух видов, сетевых интерфейсов API и пользовательских интерфейсов GUI. Подмножество того же JavaScript прекрасно нам подходит для обоих целей.



Теперь можем перечислить компоненты технологического стека Metarhia:




  • JSTP — JavaScript Transfer Protocol

  • Impress Application Server — сервер приложений, серверная среда исполнения

  • GS — Global Storage — глобально распределенная система управления базами данных

  • Console — браузер приложений, тонкий клиент или среда исполнения приложений



JavaScript Transfer Protocol это не только формат представления данных, но и протокол, который имеет специальные конструкции, заголовки, пакеты, разделители, в общем, все то, что обеспечивает реализацию прозрачного для приложений взаимодействия по сети. JSTP объединяет клиентскую и серверную часть так, что они становятся одним цельным приложением. Можно расшаривать интерфейсы и делать вызовы функций совершенно так же, как если бы функции находились локально. С единственным ограничением, что локально функции могут быть синхронные и асинхронные, а расшаренные по по сети функции всегда асинхронные, т.е. возвращают данные не через return, а через callback, который принимают последним аргументом, как это принято в JavaScript. Так же JSTP поддерживает трансляцию событий по сети, обернутую в сетевой аналог EventEmitter. У JSTP много возможностей, но сейчас приведу только основные его особенности и преимущества:




  • Встроенная поддержка интерактивности (поддержка событийно-ориентированного взаимодействия),

  • Простой и понятный известный всем формат (не нужно придумывать еще одного стандарта сериализации),

  • Асинхронность вызовов (не блокирующий принцип использования одного соединения с мультиплексацией),

  • Двунаправленное взаимодействие, максимально приближенное к реальному времени,

  • Реактивный принцип взаимодействия (код в реактивном стиле может быть распределенным),

  • Оптимизация парсинга сетевых пакетов при помощи механизма скрытых классов V8,

  • Использованием метаданных, моделей (схем данных), интроспекции и скаффолдинга.



Теперь подробнее о последнем пункте. Метаданные позволят нам не только сделать систему гибче, но и оптимизировать ее еще дополнительно, кроме того, что мы уже используем оптимизацию V8 для парсинга JSTP. В большинстве форматов сериализации имена полей тоже передаются, в JSON они занимают по грубым оценкам от 20% до 40% от всего объема передаваемых данных, в XML этот процент гораздо выше половины. Имена полей нужны только для мнимой человекочитаемости, хотя как часто люди читают XML или JSON? Для JSTP есть два варианта сериализации, это полная форма и сокращенная, построенная на базе массивов с позиционных хранением ключей. Другими словами, мы один раз передаем схему, имена полей, их типы, другие вспомогательные метаданные из которых на клиенте строим прототип. Потом мы получаем множество экземпляров объектов, сериализованных в массивы, т.е. имена полей не передаются, а структура массива позиционно соответствует структуре прототипа, у которого определены геттеры и сеттеры. Мы просто присваиваем массиву прототип, он остается массивом, но мы можем работать с этим экземпляром, через имена полей.



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



Теперь становятся понятными основные идеи технологического стека Metarhia и JSTP, как его базовой составляющей:




  • Фокус на структурах данных, а не на алгоритмах,

  • Минимизация трансформации данных: один формат для постоянного хранения данных на диске или в базе данных, представления данных в оперативной памяти на сервере и клиенте, сериализации и протокола для передачи по сети, для описания схем данных, для описания пользовательских интерфейсов, для языка запросов к данным, для интеграции и обмена данными между приложениями и системами.



Как говорит Линус Торвальдс: "Плохие программисты беспокоиться о коде. Хорошие программисты беспокоиться о структурах данных". А Эрик Рэймонд выразил это еще точнее "Умные структуры данных и тупой код работают куда лучше, чем наоборот".



Теперь короткие примеры JSTP:




  • Сериализация структуры данных: { name: 'Marcus Aurelius', birth: '1990-02-15' }

  • Полная сериализация объекта: { name: 'Marcus Aurelius', birth: '1990-02-15', age: () => {...} }

  • Метаданные: { name: 'string', birth: '[Date]' }

  • Краткая позиционная сериализация: ['Marcus Aurelius','1990-02-15']

  • Сетевой пакет: { call: [17, 'interface'], method: ['Marcus Aurelius', '1990-02-15' ] }



Сравним описание одних и тех же данных на XML, CLEAR, JSON и JSTP:



Пример XML




Seatingsnone
OK

Flap01open
OK

Flap02closed
overload

Jointdetach
OK




Пример CLEAR
1: PT004:OilPump Displacement[constant] Value[63] Control[automatic] Status[working]
2: #FlowMeter Substance[fluid] Recording[off] Role[master] Period[00:30] DataOutput[Parent.FT002.Verification]
2: #Outlet Pressure[180] Status[working]
2: #FailureSensors:Table [Module,Indication,Status]
3: [Seatings,none,OK]
3: [Flap01,open,OK]
3: [Flap02,closed,overload]
3: [Joint,detach,OK]


Пример JSON
{
"name": "PT004",
"type": "OilPump",
"displacement": "constant",
"value": 63,
"control": "automatic",
"status":"working",
"flowMeter": {
"substance": "fluid",
"recording": "off",
"role": "master",
"period": "00:30",
"dataOutput": "Parent.FT002.Verification"
},
"outlet": {
"pressure": 180,
"status": "working",
"failureSensors": [
["Module", "Indication", "Status"],
["Seatings", "none", "OK"],
["Flap01", "open", "OK"],
["Flap02", "closed", "overload"],
["Joint", "detach", "OK"]
]
}
}


Пример JSTP
{
name: "PT004",
type: "OilPump",
displacement: "constant",
value: 63,
control: "automatic",
status:"working",
flowMeter: {
substance: "fluid",
recording: "off",
role: "master",
period: "00:30",
dataOutput: "Parent.FT002.Verification",
},
outlet: {
pressure: 180,
status: "working",
failureSensors: [
["Module", "Indication", "Status"],
["Seatings", "none", "OK"],
["Flap01", "open", "OK"],
["Flap02", "closed", "overload"],
["Joint", "detach", "OK"]
]
}
}


Пример JSTP минимизированный с применением схемы данных:



["PT004","OilPump","constant",63,"automatic","working",
["fluid","off","master","00:30","Parent.FT002.Verification"],
[180,"working",[["Module","Indication","Status"],
["Seatings","none","OK"],["Flap01","open","OK"],
["Flap02","closed","overload"], ["Joint","detach","OK"]]]]


А теперь внимание, самый простой парсер JSTP на Node.js выглядит так:



api.jstp.parse = (s) => {
let sandbox = api.vm.createContext({});
let js = api.vm.createScript('(' + s + ')');
return js.runInNewContext(sandbox);
};


всего 5 строк, а его использование простое и очевидное:



api.fs.readFile('./person.record', (e, s) => {
let person = api.jstp.parse(s);
console.dir(person);
});


Теперь посмотрим более сложный пример JSTP, имеющий функции и выражения:



{
name: ['Marcus', 'Aurelius'].join(' '),
passport: 'AE' + '127095',
birth: {
date: new Date('1990-02-15'),
place: 'Rome'
},
age: () => {
var difference = new Date() - birth.date;
return Math.floor(difference / 31536000000);
},
address: {
country: 'Ukraine',
city: 'Kiev',
zip: '03056',
street: 'Pobedy',
building: '37',
floor: '1',
room: '158'
}
}


Как видно, функции могут обращаться к полям самого объекта, но для этого нужно немного модифицировать парсер:



api.jstp.parse = (s) => {
let sandbox = vm.createContext({});
let js = vm.createScript('(' + s + ')');
let exported = js.runInNewContext(sandbox);
for (let key in exported) {
sandbox[key] = exported[key];
}
return exported;
};


Моя команда разработчиков и независимые разработчики готовят сейчас JSTP SDK для более чем десятка языков, а для некоторых есть уже несколько альтернативных реализаций. Тестирование функциональности и производительности JSTP мы проведем в ближайшее время. На странице спецификации внизу есть собранные ссылки, но не все, ссылки будут обновляться: https://github.com/metarhia/JSTP



Сейчас есть такие реализации:




  • JavaScript для Browserа

  • JavaScript для Node.js и Impress Application Server

  • C and C++ for STL and Qt

  • Swift and Objective-C for iOS

  • Java for Android and JavaEE

  • C# for .NET

  • Python, Haskell, PHP, GoLang



Ссылки





Заключение



А в следующий раз я расскажу про другие компоненты стека технологий. Несмотря на кажущуюся простоту решений, сделать еще нужно очень много. Я обещаю периодически публиковать результаты и проводить тесты по нагрузкам и надежности, сравнение с аналогами по функциональности и эффективности. Пока я не могу рекомендовать все это к массовому внедрению, но зимой 2016-2017 мы выпустим SDK с примерами. Над этим трудится несколько десятков человек в специально созданном R&D центре в Киевском Политехническом Институте при поддержке SinceTV. Если Вы будете следить за проектом, то надеюсь, что он еще Вам пригодится. Даже частичное внедрение уже дало свои результаты. Спасибо за Ваше внимание.





Насколько Вам интересна эта технология?
















































Проголосовал 1 человек. Воздержавшихся нет.





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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306584/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<программирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda