-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51

Habrahabr/New








Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://habrahabr.ru/rss/new/.
Данный дневник сформирован из открытого RSS-источника по адресу http://feeds.feedburner.com/xtmb/hh-new-full, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

Как программисту получить свой первый оффер

Вторник, 25 Июля 2017 г. 20:38 + в цитатник
image
Этот вопрос, пожалуй, волнует многих людей, особенно выпускников ВУЗов. В данной статье я опишу, как и какими способами можно получить ваш первый оффер программиста. Я искала позицию java-developer, однако не думаю, что алгоритм поиска работы будет сильно отличаться в зависимости от выбранного вами языка программирования.

Прежде всего, подумать о своем будущем программиста, следует хотя бы за несколько месяцев до начала самих поисков. Алгоритм простой:
  1. Выбор языка программирования
  2. Усиленное чтение документации с последующим решением задачек, разбором примеров и чтение подходящих статей.
  3. Когда хоть какая-то база уже есть, следует придумать себе какой-нибудь несложный проект, в котором вы будете использовать все то, чему научились.
  4. Придумываем проект сложнее, параллельно не забываем о том, что надо изучать сопутствующие технологии.
  5. Желательно все это выкладывать на гит, чтобы в будущем работодатель видел, что процесс обучения у вас шел. О пользе гита я расскажу чуть ниже.
  6. Заведите себе друга программиста, который время от времени мог вам давать советы или менторить вас (это, конечно, кому как повезет). В целом, лучше не надеятся на чью-то помощь, а делать и развиваться самим.



Теперь каждый пункт подробнее


Выбор языка программирования


Если вы студент учащийся на технической специальности, то предполагается, что вы знакомы как минимум с 3-4 языками программирования и имеете примерное представление о том, чем хотите заниматься. Далее вам придется выбрать между тем, что вам нравится и тем, что будет приносить прибыль и большие перспективы. Например, если вам нравится Pascal, то скорее всего работу программиста на Pascal вам будет довольно тяжело найти, разве что в школе, учителем программирования. Соответственно зарплата у вас будет небольшая и перспективы роста довольно туманные(поправьте меня если это не так, я изучала Pascal только в школе и больше он мне ни где не встречался и я не слышала, чтобы на нем делались какие-либо масштабные проекты. Это всего лишь пример). Если вас такой вариант не устраивает то идем на сайт – TIOBE Index for July 2017 и смотрим какой самый популярный и прибыльный язык программирования и выбираем из них. Если то, что вам нравится совпадает с тем, что популярное и прибыльное – радуемся жизни и изучаем язык.
В случае если вы занимались всю жизнь, к примеру, маркетингом, и вдруг решили переключиться на программирование, то можете смело выбирать из того списка языков и начинать его изучать. В таком случае, конечно, вам придется потратить гораздо больше времени на изучение языка и сопутствующих с ним технологий ибо предполагается, что у вас есть хоть какая-нибудь университетская база.

Усиленное чтение документации с последующим решением задачек, разбором примеров и чтением подходящих статей


Когда вы выбрали язык программирования, можно переходить к данному пункту. Повторюсь, поскольку я выбрала именно Java, на примере данного языка и буду описывать все способы.
Я купила книгу для изучения Java, автор Шилдт параллельно стала открывать javaDoc и читать его(документация по Java, да и вообще почти по каждому языку программирования, если это не 1С, как правило, на английском. Следовательно, желательно чтобы и по нему была хоть какая-то база). Параллельно решала задачки, смотрела туториалы на youtube(их полно! Много материала на каждую тему!) и делала мини-проекты. Я перешла с языка программирования PHP, я работала с ним примерно полтора года, соответственно программировать я хоть как-то могла и по этой причине ознакомление с Java прошло довольно быстро.
На счет материалов по Java, привожу самые толковые, на мой взгляд туториалы, книги и курсы.

Онлайн курсы:
  • JavaRush — для самого начала довольно неплох.
  • Coursera — можно найти много курсов и не только по Java.
  • Codecademy — для самого начала пойдет.

Книги:

Видео туториалы:

На английском:
  • thenewboston — много интересных и полезных уроков
  • Derek Banas — разработка игра на Java


Cоздаем несложные проекты



В этом пункте, я думаю, все ясно. Если у вас проблемы с фантазией, вот вам несколько идей для реализации несложных проектов.
  • транспонирование, умножение, сложение и другие операции с матрицами — Довольно полезно для понятия массивов и циклов.
  • Любые задачки на рекурсию, факториалы – поиграйтесь с работой функций.
  • Создание блокнота — потренируетесь работать с чтением и записью в файл.
  • Создание галереи фотографий – работа с фото.
  • Немного посложнее – сделайте чат, хотя бы однопоточный – попробуете сокеты и системы ввода и вывода.
  • Сделайте динамичный сайт на Spring с использованием БД. – попробуете CRUD операции.


Параллельно проходите тесты. Вот несколько сайтов на которых очень много различных тестов.
  • quizful — ну совсем много тестов и не только по Java
  • muliver — тесты по-проще
  • IT.MAIL.RU — объемный тест по Java


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

Если вам нравится создавать десктопные приложения – то это соответствующие технологии. У Java, для примера – JavaFX, swing. К этому всему добавляется знание баз данных как реляционных так и нереляционных. Самые популярные БД.

Создание “боевых" проектов


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

Теперь опишу небольшой лайфхак как получить бесплатное обучение и небольшой опыт работы. Это различные стажировки, их много и они полезные. Стажировки, как правило, проводят большие компании, на стажировках вас обучают, вы делаете проект, вас менторят и на выходе вы получаете знания + опыт + опыт работы в комманде + проект. Стажировки, обычно, бесплатные, но вам и так платят бесплатным опытом работы и неплохим проектом. Если все у вас хорошо, то компании, при которых вы проходили стажировку могут предложить вам работу, однако не стоит на них полагаться, это лотерея, все зависит от того, к какому hr-менеджеру вы попадете, к какому техлиду, в каком он будет настроении. Причин брать вас или нет — тысячи и порой они очень абсурдны. На стажировку может попасть почти любой студент или выпускник, длительность стажировки примерно от 3 до 6 месяцев. Данный путь самый простой и, на мой взгляд, самый правильный. Если у вас не получилось и вам после стажировки не сделали оффер – не расстраивайтесь. Делайте дальше проекты и выкладывайте их на гит. Идти на следующую стажировку, если вы не студент 3-4 курса и особо не торопитесь устроиться на работу, смысла нет. Идите устраиваться на работу сейчас, а не тратьте время еще на одну стажировку, на которой вам может повезти а может и нет.

Список стажировок:

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


Cоставление резюме


Хорошим тоном считается писать резюме на английском языке. Английский — важен и нужен и, в IT-сфере рано или поздно вы с ним столкнетесь в полной мере. Работодателю важно чтобы вы в своем резюме максимально подробно описывали такие пункты как: где вы учились, что учили, что делали, какой средний балл(некоторым компаниям это тоже важно), какие технологии знаете, какие проекты делали, как обучались, владение иностранными языками, ваши цели, ССЫЛКИ на проекты(это повышает ценность вашего резюме в разы), если у вас есть публикации, то и на них тоже приводите ссылки. Почти везде используются системы контроля версий, именно по этой причине вам тоже лучше за ранее научиться использовать их. Это тоже повысит ценность вас как специалиста и сделает немного ценнее ваше резюме. Не бойтесь лить много «воды» в вашем резюме – это помогает рекрутерам понять, что у вас нет проблем с изложением своих мыслей (это тоже очень важно) и вы можете изъясняться так, чтобы другие вас понимали.

Дальнейшие шаги


Когда у вас есть небольшой опыт, база знаний, несколько рабочих проектов и нормально составленное резюме, смело начинайте рассылать его везде, где только можно. Не ждите, что звонки от рекрутеров посыпятся на вас на следующий день и не расстраивайтесь, если их мало. В конце концов, вы не техлид Oracle с опытом работы > 10 лет. Ходите на ВСЕ собеседования и решайте ВСЕ тз, даже если вы знаете, что не пойдете в эту компанию. Для вас это опыт и он довольно ценный. На собеседованиях обычно спрашивают стандартные вещи которые вы можете узнать здесь -> Вопросы для Java junior developer Вопросы самые банальные, за 2-3 недели, сидя с компом, можно легко подготовиться.

Свой первый оффер я получила после 3 недель поисков работы и после 8 собеседований. После каждого собеседования я прорешивала все задачки, на которых засыпалась и разбирала вопросы, которые мне были непонятны. Это очень полезно, так как вопросы обычно примерно похожие и с каждым разом вам будет все проще и вы будете чувствовать себя более уверенно. Также я наполняла гит проектами, что тоже повлияло на звонки и пришлашения, но об этом я писала уже выше. Я целенаправленно шла в большую иностранную компанию так как лично для меня то, что компания большая и иностранная — большой плюс. Не соглашайтесь на первый оффер, только если это не компания, в которую вы мечтали попасть. Если у вас есть первый оффер, второй и последующие получить гораздо проще и условия можно попросить себе гораздо лучше. Что и говорить, мой знакомый программист после третьего оффера повысил себе ЗП в два раза.

Суммарно, поиски работы заняли у меня около месяца, зато я нашла именно то, что искала. К моменту соглашения у меня было уже в запасе 4 оффера и я могла спокойно между ними выбирать. Я, на сколько это было подробно, описала весь путь от начала изучения языка программирования до получения оффера. Если у вас есть вопросы, задавайте. Не бойтесь быть активными, инициатива привествуется, мало кому интересно работать с овощами…

P. S. Я планирую написать цикл статей по Spring и его применении, включая Spring Security, Spring Boot, Hibernate и работу с различными форматами данных. Кому это интересно, напишите в комменты.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334122/


Метки:  

Отправляем рутину и бюрократию в прошлое или как большим и средним предприятиям оставаться на вершине айсберга

Вторник, 25 Июля 2017 г. 19:03 + в цитатник
Довольно часто так случается, что с ростом предприятие превращается из динамично развивающегося в медленно разлагающееся. Предприятие обрастает формализмом и от него истощается болотистый запах и вроде цели благородные – спасти от злого умысла внешних или внутренних угроз, но в итоге предприятие зарастает сводом приказов, в которых и разобраться, то довольно проблематично, я уже не говорю про то, чтобы исполнять. Т. е. с одной стороны рынок диктует условия, в которых нужно упростить жизнь потребителю, с другой стороны защита предприятия должна выдерживать напасти окружающей среды. И как же здесь быть?

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

Сразу скажу, когда результат будет близок к 0:

1. Руководитель не знает конкретной цели, чего он хочет от предприятия, от сотрудников, что будет результатом выполнения цели. По моей субъективной оценке, менее 10% руководителей «могут», а остальные говорят, что конкретно нужно делать или как нужно делать или делают сами и в итоге получают то, чего не хотят. Хотите проверить, есть ли цель на Вашем предприятии – проведите эксперимент: пусть сторонний человек спросит 5 разных человек с разных подразделений на Вашем предприятии чем занимается предприятие и что является самым главным на Вашем предприятии. Если совпадающих ответов не будет – вывод очевидный. Если подчиненные не знают цели – будем считать, что цели нет (спросите у матросов на корабле куда они плывут). Вы только представьте, что в лодке плывут несколько человек и у каждого свое весло, если все они не договорятся куда плыть, то где они будут со временем?

2. На предприятии нет и не будет процессного подхода в управлении, т.е. предприятие в целом должно быть охвачено процессами от верха до низа. Должно быть понятно, кто, что, когда и почему делает с описательной частью на бумаге. Где вход и что имеем на входе и где выход и что должно быть на выходе. Реализация процесса индивидуальна и не принципиально как Вы будете это делать — через рабочие инструкции или через «Карты процесса». Эти процессы должны быть живые, прозрачные, понятные и максимально простые (последнее очень важно!). Если эти процессы нарисованы в виде блок схем, связывая все процессы воедино – то мы в итоге получаем предметную область для переговоров внутри предприятия. Становиться гораздо проще понять друг друга.
Классическая ситуация, есть проблема, которая понятна на уровне специалиста, но в районе центра принятия решений – у руководителя проблема настолько размазывается в процессе описания, что уже не всегда понятно, а в чем собственно дело. И начинают принимать решения, не направленные на причину.
Другой пример, приходит новый сотрудник и ему говорят, что нужно ознакомься вот с этими талмудами всех приказов и распоряжений, что зачастую приводит к тому, что человек, обычно забрасывает это дело и пытается на устно-вербальном уровне от окружающих получить основную информацию для начала работы, делает ошибки и в итоге методом проб и ошибок через пол года – год становиться специалистом, хотя в процессном подходе уже через месяц будет таковым.
Или вот, например, описанные и утвержденные на бумаге для прохождения сертификации, ISO, ГОСТа и пр. или для удовлетворения жажды «биг боса» документы, могут приносить гораздо больше толка если будут процессно описаны, ведь то, что они на бумаге хорошо, но когда они по факту используются это совсем другое дело. Лучше один небольшой простой процесс, который рабочий, чем масштабный детальный и существующий в таком виде только на бумаге. Если у нас есть максимально простой и понятный механизм – участники процесса быстрее и четче будут понимать друг друга. По аналогии с матросами на корабле – представьте, что каждый гребет по своему усмотрению, когда ему вздумается.

3. У руководителя нет и не будет времени на занятие этим процессом. Нет вовлеченности, нет контроля за результатами – соответственно нет и результата.

4. Руководитель не настроил обратную связь с подчиненными таким образом, что не знает о проблемах и проблема не устраняется до катастрофы. Если в фирме заведено решать проблемы только сверху вниз, по типу есть приказ — выполняйте, то зачастую фирма будет вынуждена заниматься тушением пожаров вместо их предотвращения.

Нус приступим. Концепция УБПС.

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

2. Правила распределения бонусов. Вот здесь и начинается самое интересное. Я лучше поясню на очень упрощенном примере.
Вы собственник оптовой компании и в Вашей компании 10 человек: 5 в продажах, 3 в закупках и 2 в администрации. Вы общими усилиями посчитали, что всю работу на текущий момент можно оценить в 100 бонусов. Из них 50 бонусов — на продажи, 30 – на закупку и 20 на администрацию. Допустим, мы эти бонусы распределили поровну на каждого по 10 бонусов на человека. Тогда если фонд премирования в этом месяце составил 1 млн., то каждый сотрудник получит по 100 тыс. премиальных (1 млн. / 100 бонусов х 10 бонусов).

На следующий квартал собственник ставит цель улучшить после продажное обслуживание клиентов, чтобы доля повторных заказов наших клиентов увеличилась с 5% до 20%. На эту цель решили отдать 5 бонусов. Прошло обсуждение, нашлись желающие и ответственный. Ответственным оказался 1 человек из продаж в команде из 3 человек (1 человек из администрации и 1 человек из закупок). Эти 3 человека описали процесс. На совещании утвердили (защитили) процесс и распределили 5 бонусов в соответствии с ролями.

Прошел месяц. Доля повторных заказов увеличилась с 5% до 10%, но лояльность клиентов в целом улучшилась по результатам анкетирования. Т. к. цель не достигли в полной мере то достижение цели оценили в 3 бонуса из 5 максимальных. Прибыль увеличилась до 1,16 млн. На совещании по итогам месяца руководитель раздал еще 1 бал сотруднику из продаж за новаторство и 1 бал сотруднику из администрации за устранение возможного штрафа контролирующего органа.

Итог: один бонус в новом месяце = приблизительно 11 тыс. руб. (1,16 млн / 105 бонусов) и в целом выиграли все, особенно участвующие в новом процессе. Таким образом кто, мог и хотел взять на себя бремя – получил за это денежную награду. Со временем количество бонусов будет увеличиваться, и те, кто ничем новым заниматься не хочет, будет получать в среднем то же жалование, или даже меньше, ну а ведущие специалисты будут повышать свой и доход компании в целом.

Кроме того, достигается такие задачи как:
— работа всех сотрудников в связке над достижением цели, мы боремся за увеличение всего пирога, а не только за свой кусочек;
— вытаскивание и использование скрытых ресурсов сотрудников, использование инициативы одного во благо для всех;
— человеко-ориентированный подход, ценные кадры будут обеспечивать постоянный драйв, проложенный в нужном направлении.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334116/


Метки:  

Тестирование в Badoo «с высоты птичьего полёта»

Вторник, 25 Июля 2017 г. 18:37 + в цитатник

История бренда Nike

Вторник, 25 Июля 2017 г. 18:35 + в цитатник

Метки:  

Стартап глазами разработчика. Какой framework лучше выбрать

Вторник, 25 Июля 2017 г. 18:19 + в цитатник
Мы живем в такое время, когда люди устали делать те или иные операции вручную и готовы платить деньги за то, чтобы за них это делали другие. Причем неважно, идет ли речь о записи к врачу, поиске подрядчика, выгодных авиабилетов, уборке дома или приготовлении вкусного домашнего обеда.

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

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



И сегодня в нашем посте Николай Надоричев, лидер front-end разработки Программы «Единая фронтальная система» Сбербанка, расскажет о своем видении стартапов, о распространенных ошибках и о том, как с помощью технологии React создать приложение за один вечер.

Подходы к разработке


Что мы знаем о разработке стартапа? Она состоит из нескольких этапов:

  1. Proof of concept
  2. Получение инвестиций
  3. Сбор команды
  4. Разработка MVP
  5. Презентация инвестору и получение нового раунда финансирования

Многие стартапы совершают ошибку, пытаясь разработать MVP до похода к венчурным фондам. Это приводит к тому, что со временем мотивация команды падает, и увеличивается вероятность того, что проект не увидит свет. Чтобы этого не случилось, необходимо четко понимать, когда стоит остановиться и выводить продукт вовне. Если взглянуть на консалтинговые компании, то можно увидеть, что многие их продукты проходят стадию presale, когда время на разработку жестко фиксируют, чтобы не допустить разбазаривания ресурсов компании.

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

Причины неудач


Мы придумали стартап, он классный, но не выстрелил. Почему?

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

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

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

Стек технологий


Фреймворк


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

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

  • поддержка сообществом
  • продвижение гигантами IT-индустрии
  • легкость освоения
  • зрелость технологии.

Начнем по порядку. Поддержка сообществом подразумевает количество npm-пакетов, которые могут расширить функционал приложения, а также количество коммитов в проекте от внешних разработчиков. Далее обратим внимание на продвижение гигантами IT: каким бы хорошим продукт ни был, всегда важна его узнаваемость. Если у продукта за плечами стоит огромная корпорация, то велик шанс того, что он внезапно закроется, превратив ваш мегапроект в кучу legacy-кода. Третий немаловажный факт — легкость освоения. На мой взгляд, здесь не нужны дополнительные комментарии: зачем разрабатывать на фреймворке, который убьет много времени на освоение? И последний по списку, но не по важности параметр — зрелость. Как долго технология существует на рынке? Как активно развивается? Ответив на эти вопросы словами «давно» и «активно», можно говорить о том, что технология вам подходит.

Исходя из этих соображений, мы в Программе «Единая фронтальная система» выбрали основным фреймворком для разработки React. Почему? Давайте пройдемся по всем пунктам: для React существует огромное количество написанных элементов UI, библиотек для управления состоянием приложения и других модулей. Это делает возможным не делать часть своей работы — можно просто взять готовый компонент и встроить его в приложение.

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

При всех преимуществах React имеет ложку дегтя в виде сложной настройки проекта. К счастью, Facebook позаботился об этом и выпустил проект Create React App. Он изначально заточен на быстрый старт проекта с переходом от идеи сразу к разработке.

О том, как создать приложение на реакте за один вечер, Николай рассказал на конференции. Смотрите видео-инструкцию.




UIKit


Позволить себе создать свой собственный уникальный набор UI-компонентов могут только компании, у которых уже есть отдельная команда для разработки UIKit'а. Известны истории, когда UIKit разрабатывается всеми продуктовыми командами совместно, но у этого подхода есть ключевой недостаток: чем больше разработчиков, тем больше мнений. И в конечном счете это приведет к тому, что каждая команда будет перетягивать одеяло на себя.

Но наша цель — выпустить MVP в короткие сроки. На просторах сети есть множество готовых решений, как платных, так и open source. Можно назвать несколько популярных:


У каждого из них свой дизайн, остается только выбрать, какой больше нравится.

MVP


Или Minimum Viable Product — минимально жизнеспособный продукт. Он подразумевает то, что есть некоторый минимум приложения, который обеспечивает подтверждение концепции. Его основная цель — в том, чтобы показать, что продукт имеет право на жизнь. Он не требует детальной проработки архитектуры баз данных, работе под высокой нагрузкой и красивого дизайна. Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.

И главное — не забывайте всегда думать о будущем проекта. Надо понимать, нужен ли продукт, каковы его дальнейшие перспективы. И если вы честно ответите себе на этот вопрос положительно – тогда стоит рваться в бой и побеждать. А вы пробовали участвовать в стартапе или организовывали свой? Какие успехи? Приглашаем к обсуждению в комментариях. 
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333642/


Метки:  

[Из песочницы] JetBrains MPS — IDE для разработки проблемно-ориентированных языков программирования

Вторник, 25 Июля 2017 г. 17:38 + в цитатник

Введение


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

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

Документация очень подробная, описывает все возможности, но если нет осознания «что я делаю и зачем мне это делать», то она вряд ли будет полезна. Также есть серия уроков от JetBrains на YouTube, но опять же, я более-менее начал понимать, что происходит, только после двух просмотров всей серии и досканального изучения предлагаемых sample проектов.

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

Концепция


MPS (дальше — среда / MPS) предоставляет возможность создавать модули двух типов — Language и Solution. Первый является описанием языка и его аспектов, второй используется для разработки каких-либо проектов, тестирования языка / языков, расширений языков.

Я начну с Language.

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

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

Следует заметить, что написание кода в формате MPS немного отличается от написания текста программы, потому что мы на самом деле редактируем AST (Abstract Syntax Tree), а то, что мы видим в редакторе кода — проекция AST.

Итак, 1 статья — 1 кусок конечного проекта.

Создаем проект в MPS


MPS_1_START

На данном этапе мы выбираем название проекта и название языка, также можно создать Sandbox solution — модуль, в котором мы будем смотреть, как работает наш язык.

image

У нас есть пустой проект. Совсем пустой. Но в языке WeatherPrediction есть вложенные директивы — structure, editor… Это аспекты языка — в них мы описываем поведение языка в разных ситуациях. Например, structure содержит основные концепты языка, а editor — то, как они будут отображаться в редакторе кода. Это должно звучать очень абстрактно, особенно если Вы еще не знакомы с MPS. Понимаю. Так что сразу в бой.

Сначала нам нужно объявить root концепт языка. В переводе на русский — мы создаем некую структуру, которая будет обобщать все другие структуры. В Java это был бы

Пример root концепта на Java
public class Weather{

}

Чтобы создать концепт, тыкаем ЛКМ по WeatherPrediction -> New -> Concept.

image

У концепта есть 3 типа данных, которые он может содержать:

  1. properties — здесь можно хранить любые примитивные данные, аля строки, числа и boolean Абстрактный пример — целочисленная переменная, у которой должно быть name: string, value: integer, final: boolean

  2. children — здесь хранятся элементы других концептов. Как абстрактный пример, для концепта Program туда можно было бы пихнуть массив Statement

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

Назовем его PredictionList, определим его как root концепт и наследуем интерфейс INamedConcept.

image

Что здесь происходит: Мы определяем концепт, называем его PredictionList, говорим, что его можно реализовать как root концепт и наследуемся от INamedConcept. Если посмотреть на его definition (Ctrl + B)

image

то мы увидим, что это interface concept, у которого есть property name: string, что, собственно говоря, логично из названия

Обратите внимание, что синтаксис похож на язык программирования. Это так: этот код написан на языке jetbrains.mps.lang.structure, который описывает концепты языка.

Если мы сейчас соберем проект и захотим посмотреть, что получилось, то нам нужно будет создать модель в модуле WeatherPrediction.sandbox.

image

ЛКМ на sandbox(generation required) -> New -> PredictionList

image

Заменим no name на Saint Petersburg

Бум! У нас есть дефолтная визуализация концепта. Чтобы посмотреть AST, нажмите на любое место в редакторе и нажмите хоткей Alt + X

image

Здесь видна структура всего всего, это очень круто и удобно отслеживать состояние дерева. Сразу видим, что name у PredictionList = Saint Petersburg. Так, это очень здорово, но мы же хотим чтобы все было по красоте, поэтому мы открываем редактор концепта PredictionList и создаем ему editor aspect. Нажимаем на зеленый плюсик в нижнем списке, прямо под кодом нашего концепта, выбираем Editor -> Concept Editor

image

Здесь мы можем описать то, как будет отображаться наш PredictionList в редакторе кода.
Пока не будем вдаваться в подробности, как тут это все сделано, просто пишем [- и у нас создается массив ячеек. Все просто: в каждой ячейке — какой то константный текст / property / reference / children. И да, отображение описывается другим языком — jetbrains.mps.lang.editor.
Мы хотим, чтобы наш список предсказаний погоды выглядел следующим образом:
Weather prediction rules for %name%.

Так и пишем.

image

В первой ячейке — константный текст, во второй — {name}, обращение к property по ключу name.

Пересобираем наш язык (Ctrl + F9) и смотрим в Sandbox solution, где мы до этого создали пустой PredicitonList по имени Saint Petersburg.

image

Все работает, AST то же самое, что и до наших модификаций.

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

Спасибо за внимание! Пожалуйста, все пожелания, непонятки и вопросы и пишите в комменты. Если вопросы конкретные и простые, отвечу в комментариях, иначе добавлю в следующий пост.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334108/


Метки:  

Вводим рейтинг участника GitHub и StackOverflow на «Моём круге»

Вторник, 25 Июля 2017 г. 17:14 + в цитатник
Две недели назад мы на «Моём круге» ввели рейтинги участников «Хабра» и «Тостера», о чём рассказали в нашей прошлой публикации. А сегодня рады сообщить о добавлении рейтингов участия ещё в двух сообществах: GitHub и StackOverflow.

На профиле пользователя это выглядит следующим образом:

image

На поиске кандидатов или на откликах к вакансии — так:

image

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

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

Далее расскажем, какие данные мы выводим из GitHub и StackOverflow и что они означают.

Итак, блок участника GitHub или StackOverflow появляется на профиле пользователя «Моего круга», если у него есть хотя бы 1 репозиторий или 1 ответ соотвественно. Из блока участника можно перейти в профиль пользователя в данном сообществе и посмотреть подробней, какие именно репозитории и на каких языках он поддерживает, на какие темы и как именно отвечает.

GitHub


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

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

StackOverflow


В блоке StackOverflow мы показываем число вопросов и ответов пользователя в этом сообществе.

Далее мы выводим 10 тем, в которых пользователь внес наибольший вклад, с сортировкой о наибольшего вклада к наименьшему. Если в сообществе StackOverflow пользователь заработал золотой, серебряный или бронзовый бэйдж по данной теме, то мы обозначаем это звёздочкой соответствующего цвета. При наведении на звёздочку видна статистика пользователя по данной теме. Подробней о бэйджах на SO (смотри секцию Tag Badges). По каждой теме можно перейти и просмотреть список ответов пользователя по ней.



Напоминалочка


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

Блоки участника ИТ-сообществ подключаются и отключаются в кабинете своего профиля на «Моём круге», в разделе «Ключница».
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334102/


[Перевод] Неужели люди могут писать безумный код со множеством побочных эффектов в одном выражении и не краснеть?

Вторник, 25 Июля 2017 г. 16:19 + в цитатник
В нашей внутренней рассылке по C# программисты часто спрашивают, как правильно интерпретировать выражения, подобные этим:
    a -= a *= a;
    p[x++] = ++x;

А я в свою очередь спрашиваю: «Кто в здравом уме пишет такой код?». У меня только одно объяснение: эти люди пытаются выиграть «Международный конкурс запутывания кода на С» или пишут программу-головоломку. В любом случае они должны понимать, что делают что-то очень странное. Серьёзно, неужели существует человек, которые пишет a -= a *= a и p[x++] = ++x; в уверенности, что его код великолепен?



Эрик Липперт (Eric Lippert) говорит: «Да, такие точно есть». В качестве примера он привел книгу одного автора, чей успех не вызывает вопросов: куплено более четырех миллионов экземпляров, и продажи продолжают расти. По мнению этого автора, чем код короче, тем быстрее он исполняется. Автор использовал несколько операций с побочными эффектами в одном выражении, тернарные операторы, как будто их скоро запретят, и в целом считал, что время выполнения пропорционально количеству точек с запятой, а от каждой переменной где-то в мире умирает щенок (на самом деле нет, пусть все щенята живут счастливо).

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

Во-первых, обеспечена уйма ложных срабатываний. К примеру, вы можете написать:
total_cost = p->base_price + p->calculate_tax();

В таком случае компилятор выдаст предупреждение, потому что обнаружит, что метод calculate_tax имеет тип, отличный от const, и поэтому выполнение метода может изменить значение base_price, а при этом важно учитывать, добавляете вы налог к первоначальной базовой цене или к обновленной. Но вы-то понимаете (обладая знаниями, недоступными компилятору), что метод calculate_tax изменяет налоговую юрисдикцию объекта, но не влияет на базовую цену. Значит, вы уверены, что срабатывание ложное.

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

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

«Гений программирования» Вася Пупкин считает, что его код безупречен, а компилятор делает из мухи слона: «Да ведь понятно, что значение переменной сначала увеличивается, затем эта переменная используется для вычисления индекса элемента массива, а результат сохраняется обратно в переменную. Видишь, с порядком вычислений всё в порядке. Бестолковый компилятор!». «Гений программирования» Вася Пупкин отключает предупреждение. Конечно, «гений программирования» Вася Пупкин — случай безнадежный, поэтому особенно беспокоиться о нём не стоит.

Но есть ещё и Петя-новичок, который даже не понял смысла предупреждения: «Так, что у нас тут. Я компилировал эту функцию уже пять раз, и каждый раз получал один и тот же результат. Результат, на мой взгляд, вполне похож на правду. Думаю, это ложное предупреждение». Пользователи, для которых это предупреждение предназначалось, не обладают достаточными знаниями и опытом, чтобы извлечь из него пользу.

Разумеется, через некоторое время история повторяется. Кто-то снова спрашивает, почему конструкция типа x ^= y ^= x ^= y не работает в C#, хотя в C++ проблем не возникает. Это ещё одно доказательство того, что люди пишут код с большим числом побочных эффектов, будучи при этом полностью уверенными в том, что результат вполне понятен, и код должен работать как часы.

Над материалом работали Schvepsss и PoisonousJohn (в жизни Иван Фатеев).
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334098/


Метки:  

Bluetooth SIG анонсирует bluetooth mesh сеть

Вторник, 25 Июля 2017 г. 16:12 + в цитатник
image

На Хабре уже была статья с данным анонсом, но автор решил более подробно описать концепцию и архитектуру сети bluetooth-mesh.
Сначала было желание в одной статье описать и обзор и базовые составляющие сети и архитектуру, но написав обзор, автор понял, что читатель устанет. Поэтому будут еще 2 статьи: «Базовые понятия сети bluetooth-mesh» и «Архитектура сети bluetooth-mesh».

В мире технологий продолжается гонка за первое место в объединении всех окружающих нас вещей с помощью протоколов беспроводной связи, главной особенностью которых является низкое энергопотребление.
В то время, когда альянс Wi-Fi разрабатывает стандарт «802.11ah», а консорциум Telecom — стандарт 5G, в который будет включен протокол с низким энергопотреблением, Bluetooth SIG анонсировала сеть bluetooth mesh, использующая технологию BLE (Bluetooth Low Energy). Все мы знаем, что BLE как раз и является технологией с малым энергопотреблением и, учитывая её остальные возможности, Bluetooth SIG, в конечном итоге, предлагает решение промышленного уровня. Да, именно так: «Industrial-grade Solution».

Ключевыми составляющими данной сети, по заявлению Bluetooth SIG, являются:
— надежность;
— масштабируемость;
— безопасность.

В этой статье мы кратко рассмотрим указанные выше составляющие.

Ключевые составляющие



Надежность


Как известно, надежность сети оценивается в том числе и по ее способности доставлять сообщения от одного устройства к другому. Для обеспечения бесперебойной доставки сообщений, сеть используют 2 типа связи:
Peer-to-Peer: одноранговая сеть, описанная в спецификации технологии и называемая «piconet», благодаря которой, все узлы сети могут соединяться друг с другом напрямую без дополнительных специальных узлов с функцией концентратора или маршрутизатора. Что, в свою очередь, избавляет сеть от точек отказа;
Multipath (message relay): архитектура ретрансляции управляемого потока сообщений с использованием нескольких маршрутов. В связке с простотой развертывания и управления, является надежным способом доставки этих сообщений.

Масштабируемость


Bluetooth-mesh позволяет тысячам устройств взаимодействовать друг с другом при этом удовлетворяя коммерческие и промышленные требования к производительности. Какие же это требования:
большое количество узлов: в спецификации указана поддержка до 32000 узлов сети. В настоящее время уже развернуты сети, в которых содержится более 1000 узлов. Типичный пример такой сети — это среда, в которой используется большое количество осветительных приборов. В такой среде Bluetooth-mesh быстро масштабируется, так как она специально разработана для этих целей.
скорость: малый размер пакета bluetooth вместе c высокоскоростным радио-каналом обеспечивает очень быстрый обмен сообщениями. В случае с освещением предприятия это позволяет, например, одному выключателю одновременно управлять сотнями осветительных приборов.
многоадресная рассылка: архитектура ретрансляции управляемого потока сообщений в сочетании с возможностью подписки/предоставления группового обмена сообщениями делает сеть уникальной для обработки большого объема данных многоадресной передачи сообщений. Промышленное освещение — отличный пример сценария развертывания, в котором bluetooth-mesh является идеальным решением.

Безопасность


Bluetooth-mesh использует архитектуру безопасности, которая предназначена для решения проблем безопасности компаний, развертывающих широкомасштабные сети беспроводных устройств.
Уровень управления: устройства, добавляемые в сеть, могут использовать алгоритмы 256-битной эллиптической криптографии с применением out-of-band проверки подлинности. Вся связь в сети защищена алгоритмом шифрования AES-CCM с 128-битными ключом. Таким образом гарантируется, что все сообщения в сети зашифрованы и прошли проверку подлинности.
Многоуровневость: шифрование и проверка подлинности реализуются на двух уровнях: сетевом и прикладном. Все узлы в сети могут ретранслировать сообщения на сетевом уровне, не зная его содержимое. Для обеспечения полной безопасности при доставке сообщения от отправителя к получателю, содержимое сообщения дополнительно шифруется отдельным ключом приложения.
Конфиденциальность: каждый пакет сети обрабатывается так, чтобы удалить любую идентифицирующую информацию. Это не позволяет другим отслеживать устройства сети, особенно когда эти устройства перемещаются в зоне действия других сетей.

В следующей статье мы рассмотрим базовые понятия сети.
Спасибо за внимание.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333792/


Метки:  

[Из песочницы] Генерация документов — взгляд изнутри

Вторник, 25 Июля 2017 г. 15:37 + в цитатник
Создание модуля генерации документов только на первый взгляд может показаться делом простым. На самом деле, чтобы создать такой модуль, надо решить несколько проблем, без решения которых его реализация будет неполноценной. Функционал генератора документов должен уметь решать проблемы, идущие в виде требований из реальной жизни. Рассмотрим одну из множества проблем.

Требованиe: пользователи\бизнес желают иметь библиотеку пунктов (параграфов), которые вставляются в документы, генерируемые по различным шаблонам. Изменение пункта в библиотеке должно приводить к изменению этого пункта в документах, которые генерируются по этим шаблонам. Изменять пункты хотел бы сам бизнес, без участия ИТ. Составление шаблонов (по которым генерируются документы) с учетом вставки в разные их места пунктов из библиотеки сокращает размер шаблонов, они становятся полиморфными, и, соответственно, уменьшается количество шаблонов и упрощается их сопровождение.

Начальные данные: для удобства работы с пунктами библиотека может состоять, например, из фрагментов документа, создаваемых в MS Word. Т.е. их создание и редактирование производится в MS Word. Библиотечные пункты хранятся, например, в базе данных и\или в файловой папке. Какие конкретно пункты будут вставлены в документ при генерации определяется во время исполнения приложения, которое использует модуль генератора.

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

Вторая задача более сложная. Рассмотрим пример пункта и на его основе перечислим проблемы:

[1.2] Библиотечный пункт является примером, составленным г-ном [Ивановым] для демонстрации проблем, описанных в пунктах [2.3] и [3.1] ["Краткого описания"][данного изложения]

В приведенном примере фрагменты текста, помещенные в [...] скобки, должны задаваться параметрически. Т.е. данный библиотечный пункт при вставке в реальный документ мог бы выглядеть так:

3.1 Библиотечный пункт является примером, составленным г-ном Горбунковым С.С. для демонстрации проблем, описанных в пунктах 4.1 и 4.6 "Краткого описания"

Если приложение в момент исполнения может знать о Горбункове С.С. и о том, описание это или изложение, то о том, какой именно номер пункта в шаблоне, 1.2 или 3.1, приложение не знает, да и не должно. Библиотечных пунктов может быть несколько, вставляться они могут в разные места разных шаблонов, нумерация разделов в них не совпадает, да и ссылаться пункты могут на другие пункты, номера которых не должны быть известны приложению. Приложение должно поручить задачи расчета номеров пунктов самому генератору. Шаблоны совместно с генератором должны обеспечивать нумерацию своих и библиотечных пунктов сами, впрочем, как и определение номеров ссылок на пункты.

Например, в одном шаблоне конкретный библиотечный пункт может ссылаться на пункты 4.1 и 4.6, в другом (или в этом же самом) только на пункт 2.5.1. Кроме того, если нумерация пунктов выполняется внутри одного документа, то ссылки могут ссылаться на пункты в другом документе, как, например, «Краткое описание» может быть не генерируемым в данный момент документом, а уже существующим. Все это говорит о том, что библиотечный пункт должен быть параметризован. Если генератор не может выполнять такие операции, то вносить правки в документ придется человеку вручную, а человек может ошибаться.

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

[Счетчик:X] Библиотечный пункт является примером, составленным г-ном [Наименование автора] для демонстрации проблем, описанных в пунктах [Глобальная ссылка:A][ и [Глобальная ссылка:B]] [[Альтернатива:1="Краткого описания"]|[Альтернатива:2=данного изложения]]

Итак, если модуль генератора знает, каково значение счетчика:X до вставки библиотечного пункта, знает значение поля [Наименование автора], имеет информацию о документе «Краткое описание» и может найти в нем конкретные значения глобальных счетчиков (доступных из других документов) с именами A и B этого документа, и если он знает альернативу 1 или 2, то окончательное значение библиотечного пункта вычисляется генератором по входным параметрам и данный пункт можно использовать в разных шаблонах без проблем.

Остается только добавить, что модифицировать такой библиотечный пункт в MS Word могут не только сотрудники ИТ, но и обученные сотрудники подразделений организаций. Что радует.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334090/


Метки:  

[Из песочницы] Сайт-визитка студента без затрат

Вторник, 25 Июля 2017 г. 15:02 + в цитатник

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


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


Что будет в этой статье:


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

Получение домена


Начнем с получения домена. Здесь есть два способа:


Первый: небесплатный, которым пользовался я сам


Можно зарегистрировать домен в доменном зоне .ru всего за 140 рублей. Ссылку на регистратора оставлять не буду, но он легко гуглится (или найдет вас сам в контекстной рекламе после пары соответствующих запросов). На сайте регистратора вы выбираете свободный домен, покупаете, и пользуетесь целый год (это достаточно легко, не буду останавливаться подробнее). Правда продление потом будет стоить 495 рублей в год, что тоже не так дорого, относительно других регистраторов Рунета.


Второй: бесплатный, которым пользовались мои друзья


Он сложнее, зато вы получаете бесплатно на год домен в зоне .me. Однако, продление потом будет стоить уже $18.99 (а это больше тысячи рублей) и поморочиться придётся подольше.


Если вы студент it-специальности, слово Github уже не должно вызывать вопросов (а иначе никакой сайт-визитка не поможет). Так вот, этот самый Github помогает в нашем деле дважды. Во первых, он даёт так называемый Student Developer Pack, в котором и будет наш бесплатный домен. А, во вторых, именно средствами Githubа можно бесплатно хостить сайт (но об этом позже).


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


image


После того, как вам откроют доступ к этому пакету, заходите сюда, находите в списке Namecheap, кликаете на "Get access by connecting your GitHub account on Namecheap" и привязываете свой Github аккаунт. После будет всё та же процедура выбора свободного домена, и после подтверждения им можно пользоваться.


Бесплатный хостинг


Спасибо GitHub за то, что он есть. Отдельное спасибо за GitHub Pages, который предоставляет возможность разместить один сайт для аккаунта и подключить свой домен бесплатно. Для этого нужно создать репозиторий с названием username.github.io, где username — имя пользователя, например AndreySBer.github.io. Сайт будет доступен по этому же адресу.


Хостинг сайта основан на ветке master git-репозитория. Каждый коммит в master приводит к его обновлению. Поэтому разработку и тестирование лучше проводить в отдельной ветке и потом через pull-request сливать в master.


Как связать домен и хостинг (DNS)


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


1) Указать имя домена в настройках репозитория.


image


2) Добавить файл CNAME с именем домена.


image


3) В настройках домена у регистратора в пункте DNS добавить две A записи (подробнее здесь):


  • 192.30.252.153
  • 192.30.252.154

image


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


Где взять шаблон


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


Эти шаблоны построены на основе Bootstrap, есть примеры готовых блоков для страниц, адаптированы для мобильных экранов (в большинстве).
Имея базовые знания HTML, css, Bootstrap и чувство прекрасного, можно сделать вполне приличную страницу (или несколько), закоммитить их в develop ветку репозитория, протестировать на разных экранах, и затем залить в master.


Если нужен новый лендинг — повторить.


image

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

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

https://habrahabr.ru/post/334088/


Метки:  

Кейсы JSOC

Вторник, 25 Июля 2017 г. 14:59 + в цитатник
Для меня, как аналитика, самые полезные и интересные доклады и статьи – те, которые освещают практические аспекты информационной безопасности и дают конкретные примеры инцидентов и методов их выявления и расследования. Поэтому сегодняшняя статья посвящена нескольким интересным кейсам, с которыми мы в Solar JSOC сталкивались за последнее время.

Такие нужные торренты…


В одном из наших клиентов вся сетевая активность различных приложений является объектом строгого профилирования и контроля. Исходящая сетевая активность приложений контролируется на уровне прокси-сервера, и обнаружение сетевой активности от нового «user-agent» считается событием информационной безопасности. В этом случае круглосуточная первая линия мониторинга Solar JSOC может либо эскалировать его на аналитика, ответственного за заказчика, либо самостоятельно оповестить заказчика по маршруту, установленному для этого типа инцидентов. Выбор зависит от типа сетевой активности, ее подозрительности и другой сопутствующей информации.

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

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

17 апреля 2017 года примерно в 3 часа ночи было зафиксировано успешное внешнее соединение одного из средств удаленного администрирования, осуществленное с рабочего ноутбука сотрудника технической поддержки. Отдел техподдержки – единственный, кому разрешено использование данного типа user-agent`ов, но в данном случае вместо штатного средства использовалось утилита TightVNC. Ноутбук не был подключен к Solar JSOC, поэтому аналитики первой линии не могли собрать локальные логи машины и эскалировали инцидент на дежурного аналитика второй линии, параллельно готовя оповещение заказчика по электронной почте.

Далее приведена хронология событий:
03:08:02. Инцидент.
03:26:00. Оповещение специалистом первой линии дежурного аналитика по телефону.
03:29:00. Согласование с заказчиком подключения машины на уровне локальных логов ОС.
03:32:48. Оповещение от 1-й линии в сторону Заказчика.
03:48:00. Подключение машины к SIEM-системе.

Благодаря заранее настроенному расширенному аудиту на всех рабочих станциях (в том числе мобильных) и серверах заказчика, стало понятно, что активность произошла вследствие скачивания и запуска процесса tnvserver.exe. Выявить родительский процесс помогло расширенное логирование, которое мы настраиваем у заказчиков в обязательном порядке. Им торрент-клиент, который антивирус не посчитал вредоносносным ПО.


Общая хронология событий выглядит следующий образом:

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

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

Часть антивирусных решений способна детектировать такие продукты как not-a-virus, то есть ПО, потенциально опасное для пользователя, но выполняющее при этом полезные функции. Другая часть антивирусов никак на них не реагирует.

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

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

Вместо морали в финале этой истории хотелось бы дать несколько рекомендаций:

  1. Ограничивайте возможность прямых соединений через межсетевые экраны для пользователей, используйте прокси-серверы. Они обладают категоризацией, позволяющей на основании трафика или адресов выявить использование средств удаленного администрирования.
  2. Используйте антивирусное ПО, которое умеет детектировать not-a-virus.
  3. Проводите полноценный тренинг security awareness среди пользователей.
  4. Ограничивайте привилегии пользователей на рабочих станциях. В данном случае это помогло бы предотвратить установку как основного ПО, так и дополнительных пакетов.
  5. По возможности регулируйте установленное на хостах ПО, в том числе ограничением пользователей в правах (запрет локального администратора).
  6. Агрегация репутационных баз и интеграция их в SIEM-систему позволит выявить недетектируемые образцы вредоносных программ в инфраструктуре, использование TOR, средств удаленного администрирования и пр.

Контроль служебных учетных записей


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

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

На первом этапе расследования источником информации для анализа инцидента служили серверы, на которых хранились электронные реквизиты платежной системы. Эти серверы мы подключили на уровне локальных логов ОС Windows (максимальная глубина хранения составила 2 месяца для журнала System Event Log, Security — неделя)

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

На этом этапе мы подключили дополнительные источники:
  • ретроспективные логи с пограничных и межсегментных МСЭ (агрегировались с помощью syslog-сервера)
  • локальные логи сервера ***** (далее – SRV)

Оказалось, что сделать анализ локальных логов хоста server невозможно из-за их очистки, но при анализе образа данного хоста в восстановленном и декодированном файле wtmp (записывает данные в входе и выходе из системы) были найдены записи по аутентификации под учетной записью root за несколько недель до инцидента.

Также на SRV были обнаружены следы программного обеспечения, используемого злоумышленниками для проникновения в инфраструктуру, – программные пакеты nmap (система сканирования и выявления уязвимостей) и medusa (система интеллектуального подбора паролей).

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

Это можно наглядно представить внутренними средствами HPE ArcSight:


Далее были зафиксированы значительные (свыше 10 Мбайт) сессии по протоколу smb с хоста SRV на скомпрометированные серверы. Они осуществлялись в то же самое время, что и события аутентификации из локальных логов. Вероятнее всего, пароль учетной записи techuser был скомпрометирован в результате успешной эксплуатации уязвимости протокола smb на хосте. Уязвимость позволяла пройти беспарольную аутентификацию в системе под служебной учетной записью Windows и скомпрометировать пароли учетных записей через процесс lsass.exe.

Далее под учетной записью techuser была установлена системная служба, выполняющая функции remoteshell.

Основные особенности работы данного ПО таковы:
  • Процесс установки и сборки использует только внутренние инструменты powershell, что существенно усложняет возможность его детектирования.
  • Запускается новый экземпляр системного процесса svchost.exe с динамической сборкой кода в памяти процесса, тем самым усложняя возможность его определения как вручную, так и с помощью автоматизированного ПО.
  • Для коммуникации с управляющим сервером используется порт 9887 (на сервере предварительно было добавлено разрешающее правило на локальном межсетевом экране).
  • ПО не оставляет следов на файловой системе, функционирует целиком в оперативной памяти и удаляется по факту завершения сессии/


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

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

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

  • Использование утилит удаленного администрирования или доступа к центру управления через прокси-сервер:

    • Проанализировать все факты доступа к подозрительным ресурсам/с использованием нестандартных протоколов через прокси-сервер (здесь мы предоставили выгрузку и сделали приоритизацию подозрительных активностей).
    • Введено ограничение прямого доступа в Интернет в сети компании для гарантированного перенаправления всего Интернет-трафика через прокси-сервера.

  • Аудит всех хостов компании на предмет использования ПО, применяемого хакерскими группировками для компрометации паролей (Mimikatz, procdump).

Вроде APT….или нет?


Следующий кейс, выявленный в рамках пилотного проекта Solar JSOC, выглядит очень нестандартно, так как по всем признакам он должен быть про APT – spoiler alert! – но на самом деле нет. Итак, дано:
  • Несколько вредоносов: keylogger, RAT и еще пачка других.
  • Скомпрометированная машина помощника генерального директора.
  • Злоумышленники, использовавшие этот хост несколько месяцев.

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

Сценарий работает по следующему принципу: Существует несколько активных листов – лист с ip-адресами, лист с доменами 2-4 уровня, лист с полными ссылками к вредоносным объектам. Специальный скрипт нормализует различные репутационные базы, приводя их к единому виду. Далее каждое правило работает либо с различными полями, проверяя вхождение зафиксированных на межсетевых экранах событий со строками activelist по полям target address либо request url host (target host name), либо request url.

При подключении пограничного межсетевого экрана были обнаружены обращения на известные потенциально опасные ресурсы (IP-адреса C&C-серверов), которые могли свидетельствовать о заражениях внутренних ресурсов компании вредоносным ПО.

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

Один из потенциально зараженных хостов оказался рабочей станцией помощника генерального директора компании. В результате исследования машины на ней были обнаружены следы вредоносного ПО, включая шпионское ПО Mipko Personal Monitor (MPK).

Шпионское программное обеспечение MPK было установлено на АРМ из-под учетной записи АРМ\Serv. При этом первый вход данной учетной записи на рабочую станцию был выполнен за несколько месяцев до самой установки.

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

Контроль и сбор информации осуществлялся в отношении двух учетных записей: АРМ\serv и учетной записи помощника.

Перехваченные данные каждые 8 часов отсылались на внешние ресурсы:
  • ***nks.biz по FTP
  • ******@gmail.com

Факты передачи при этом были подтверждены событиями с пограничного межсетевого экрана.

С момента первого входа под учетной записью АРМ\serv и до момента проведения расследования на хосте фиксировались множественные входящие удаленные сеансы RDP с различных внешних адресов (в среднем 10 000 соединений в сутки).

Скриншоты, собранные шпионским ПО MPK, демонстрировали весьма любопытную активность из-под учетной записи АРМ\Serv:
  • Попытки внедрения PHP-скрипта во множество сайтов.
  • Регистрация мобильных номеров, множественные регистрации различных почтовых ящиков.
  • Ввод данных по различным кредитным картам на сайтах.
  • Переводы небольших денежных сумм на различные счета/электронные кошельки и мобильные номера.
  • Совершение покупок на различных торговых площадках.

Также в результате анализа логов MPK был найден файл, в котором содержалось более 500 различных внешних IP адресов, которые доступны извне по RDP, вместе с учетными данными для подключения (логин-пароль).

По всей видимости, АРМ помощника использовали как промежуточную машину для атак на веб-сайты, кражи данных банковских карт/учетных данных пользователей этих сайтов и перевода денежных средств со скомпрометированных карт и счетов, а также обналичку через покупки. Судя по всему, зараженная рабочая станция была одной из сети скомпрометированных машин, которыми пользуются злоумышленники в своих целях.

А теперь немного техники.

В результате исследования были обнаружены следующие нелегитимные утилиты (нелегитимность подтверждена в том числе владельцем АРМ).

В ходе мероприятий по локализации активности MPK мы получили дополнительную информацию:

  • Обнаружена скрытая директория MPK, расположенная по пути: C:\ProgramData. Содержимое данной директории представляло собой PE-объекты, необходимые для функционирования «MPK», а также конфигурационные и лог-файлы.
    В результате сканирования данной директории обнаружены множественные объекты с сигнатурой JFIF (JPEG File Interchange Format), что говорит о наличии в ней изображений.

  • Обнаружены активные процессы, имеющие непосредственное отношение к функционированию «MPK»:
    mpk.exe (NT AUTHORITY)
    mpkl64.exe (NT AUTHORITY)
    lsynchost.exe (NT AUTHORITY)

  • Обнаружены успешные попытки внедрения PE-объектов (MPK64.dll и MPK.dll), являющиеся компонентами MPK, в адресное пространство активных процессов.
    В результате трассировки активных процессов обнаружен факт перехвата данных, вводимых в окна приложений и передаваемых через буфер обмена. Функционал перехвата реализован в PE-объектах: MPK64.dll и MPK.dll.

Для того чтобы установить функциональность данной сборки MPK и определить, какая информация могла быть собрана и передана третьим лицам в результате работы вредноса, мы получили с АРМ помощника следующие данные:
  • Файловая система: %SYSTEMROOT%\ProgramData\MPK\*
    %SYSTEMROOT%\SysWoW64\Mpk\*
    %SYSTEMROOT%\Prefetch\*
    %SYSTEMROOT%\inf\*
    %SYSTEMROOT%\System32\Logs\*
    %USERPROFILE%\AppData\Local\ Temporary Internet Files\*
    %USERPROFILE%\Temp\*
  • Экспорт реестра: HKEY_CURRENT_USER
    HKEY_LOCAL_MACHINE
    HKEY_USERS
  • Активный снимок оперативной памяти.

В директории «C:\Windows\MPK» были обнаружены лог-файлы, которые содержали информацию о ходе установке программного обеспечения и конфигурационных параметрах работы: mpk_em_log.txt и *.dat. В результате анализа были получены подробности установки и работы MPK:

  • Установщиком был PE-объект — mpk_emni_mpk.exe. Основные компоненты, необходимые для установки, располагались в директории C:\Users\Serv\Desktop\1\6\*.

  • В случае функционирования внутреннего брандмауэра Windows для него создавались специальные правила:



  • Учетным записям помощника и АРМ\Serv были присвоены директории с именами «1» и «2». Эти скрытые директории, расположенные в C:\ProgramData, содержали перехваченные данные.

По итогам расследования заказчику были выданы следующие рекомендации:

  1. «Перезалить» операционную систему на рабочей станции.
  2. Сменить пароли от всех учетных записей, которыми пользовались на данной рабочей станции.
  3. В случае, если служба Service-Desk подключалась к данной рабочей станции и вводила там свои учетных данные, рекомендовалось сменить пароли от них.
  4. Запретить белый IP-адрес и прямой доступ в Интернет для данной рабочей станции. Если наличие белого IP-адреса является производственной необходимостью, то использовать повышенные требования по безопасности к любым удаленным подключениям к ней:

    • Пароли повышенной стойкости;
    • Частая смена паролей;
    • Жесткое ограничение IP-адресов, с которых возможны какие-либо входящие подключения;
    • Контроль состояния антивирусного средства;
    • Изоляция рабочей станции в отдельный сегмент без доступов к внутренним ресурсам компании или со строгим ограничением такого доступа к конкретным ресурсам.
  5. Проверить всю инфраструктуру компании на наличие подобного шпионского ПО, средств удаленного администрирования, другого несанкционированного ПО.
  6. Осуществлять мониторинг критичных рабочих станций и серверов по следующим направлениям:

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

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

В этом статье я осветил лишь три кейса из многих, которые мы наблюдаем в JSOC. Инциденты случаются ежедневно, в основном рутинные, но бывают и интересные экземпляры. Учитывая их количество, думаю, скоро выйдет вторая серия обзора интересных кейсов из жизни Solar JSOC.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333816/


Секция безопасной разработки на PHDays VII: итоги встречи сообщества PDUG

Вторник, 25 Июля 2017 г. 14:36 + в цитатник


24 мая на площадке форума PHDays VII прошло очередное мероприятие сообщества Positive Development User Group. Пока за стеной хакеры увлеченно (и весьма успешно) атаковали инфраструктуру вымышленного города, мы разговаривали о том, как разработчики могут сделать свои приложения неуязвимыми для взлома.

Что из этого вышло, смотрите под катом — там собраны презентации и видеозаписи докладов.

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



Мастер-класс «Трущобы Application Security»


Владимир Кочетков, руководитель отдела исследований по анализу защищенности приложений, Positive Technologies, и Денис Колегов, руководитель группы исследований технологий защиты, Positive Technologies.




Первая часть:




Вторая часть:




Третья часть:




Автоматизация построения правил для Approof


Денис Ефремов, Институт системного программирования РАН.







Механизмы предотвращения атак в ASP.NET Core


Михаил Щербаков, независимый разработчик и консультант.







Формальная верификация кода на языке Си


Денис Ефремов, Институт системного программирования РАН.







Уязвимое Android-приложение: N проверенных способов наступить на грабли


Николай Анисеня и Сергей Тошин, специалисты отдела исследований безопасности мобильных приложений, Positive Technologies.







Требования по безопасности в архитектуре ПО


Кирилл Иванов, архитектор, Positive Technologies.







От экспериментального программирования к промышленному: путь длиной в 10 лет


Катерина Трошина, ведущий эксперт по информационной безопасности, Solar Security.







Спасибо всем, кто пришел на наш трек! В течение года мы планируем провести еще несколько тематических митапов и уже сейчас активно ищем новых спикеров и коллег по цеху, готовых поддержать популяризацию безопасной разработки. Если у вас возникнут вопросы к организаторам или докладчикам, присылайте их на pdugorg@ptsecurity.com или pdug.org@gmail.com.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334086/


Метки:  

[Из песочницы] Как я варил CLion

Вторник, 25 Июля 2017 г. 14:03 + в цитатник
История про CLion, docker, conan, cmake, ninja, cotire и gdb.

Небольшое предисловие


Разработкой на C++ я занимаюсь уже лет 15 и когда-то начинал с «Watcom С». О нем у меня остались самые теплые воспоминания. Но, так как мне больше приходилось писать для консоли UNIX, я перешел на vim в качестве IDE. В целом, он достаточно удобен. Его плагины творят чудеса, можно настроить autocomplete, просмотр иерархии классов, быстрый переход к определению или поиск, в общем всё, что должны уметь IDE, там можно поднять. Боль приходит в тот момент, когда ты пытаешься установить и освоить новый плагин. Это всё заводится не везде и не всегда, и, зачастую, жрет проц и память похлеще любой java.

Периодически я поглядывал на Qt Creator. Но так и не решился на него перейти.

Первое знакомство


imageИ вот, в один из таких моментов мне на глаза попался CLion. После конструктора под названием vim очень хотелось получить решение «из коробки». На первый взгляд, он мне очень понравился. Быстрые подсказки, удобная навигация, работа с cmake проектами, как с родными, поддержка режима vim (правда, в последствии, я её отключил).

Облом случился довольно скоро. Дело в том что, хоть пишу я на данный момент в основном под linux, в качестве рабочей станции у меня macbook pro. Да, я такой! И искренне считаю извращенцами людей, которые, купив ноутбук apple, устанавливают на него что-нибудь кроме macOS. Поэтому, для меня критически важна возможность удаленной сборки или сборки через docker. А её, сколько пользователи ни просили, в CLion пока нет. Первая попытка перехода закончилась ничем — ведь решения «из коробки» нет.

Вторая попытка


Но боль с настройкой vim никуда не ушла, и я решил дать CLion второй шанс — попробовать решить те проблемы, которые передо мной встали, самостоятельно. А это:

  1. Отсутствие локально установленный библиотек. CLion не может выдавать подсказки по классам, описания которых не видит
  2. Собственно сама сборка

До этого, я пользовался библиотеками, которые поставляются в пакетах вместе ОС. С CLion мне бы пришлось все заголовочные файлы ОС закидывать к себе на Mac, чего категорически не хотелось. Но тут меня выручил conan. Он хранит все собранные библиотеки в отдельном каталоге, который легко можно подложить себе.

Со вторым все оказалось не так просто. Я решил просто подменить cmake на свой скрипт, который выполнит сборку внутри docker контейнера. Мне не улыбалось каждый раз, когда я синхронизирую свой код из репозитория или вливаю его обратно, добавлять/удалять дополнительный Target в CMakeLists.txt, как мне советовали. Хотелось иметь возможность склонировать любой проект и тут же собраться без танцев с бубном. Это оказалось не так просто. Основную сложность вызвала сборка тестового проекта CLion, которую он выполняет при смене toolchain, и проброс параметров содержащих пробелы внутрь контейнера. Но я справился.

Если у вас всё хорошо — вы просто ещё не всё знаете


Казалось бы — у меня получилось!

Я был наслышан, что сборка на С++ с использованием С++14 или С++17 — довольно медленная штука, и, поначалу, всё списывал на медлительность компилятора. Но потом заметил, что удаленно на выделенном сервере собирается уж как-то слишком шустро. Чем больше становился проект — тем большие сомнения рождались в моей душе.

Докер оказался с двойным дном. Да, сервер поднимается шустро, вот только компиляция на osxfs работает, как оказалось в ТРИ раза медленнее, чем на overlay. Поэтому пришлось перейти на использование rsync. Так же, я открыл для себя настройки томов docker. Если использовать delegated — скорость сборки увеличивается процентов на 15. Подробнее.

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

Еще, я попробовал использовать прекомпилированные заголовки (cotire) — эффект оказался неоднозначным. К тому же, это требовало вручную формировать stdafx.h (или любой другой файл) и включать его во все .cpp. А это, в свою очередь, не очень нравится CLion. Он начинает считать все остальные include лишними. Это можно было обойти, но выигрыш был не такой значительный.

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

Аппетит приходит во время еды


Раз уж сборка у меня завелась, почему бы не попробовать растолкать и отладку!
Раньше я считал, что gdb внутри docker запустить невозможно. Оказалось, что это не так. Параметр --security-opt seccomp:unconfined снимает данную проблему. А статья подробно описывает, как и что надо настраивать. Но, и тут случился непредвиденный облом. Я собирался через clang (что логично), а для отладки надо использовать gcc. В противном случае, запустить приложение в отладчике вы сможете, но вот посмотреть значения внутри stl контейнеров уже нет. В принципе, собрать через gcc — не проблема. Тогда, и правда всё работает.

Эпилог


Мыши плакали, кололись, но продолжали есть кактус… Ждем! Ждем удаленную сборку. Ждем полноценную поддержку C++17. JetBrains и JFrog в своих рассылках постоянно поминают друг друга, но какой-либо интеграции пока нет. Даже, собираясь локально, придется вводить команды conan вручную. Ждёмс!

Еще было бы неплохо заполучить поддержку сборки через ninja. 50% производительности на дороге валяются.

Кому интересно, мои скрипты и Dockerfile для сборки шаблона можно найти на GitHub.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334080/


Метки:  

[Перевод] Сила минимализма в UX дизайне

Вторник, 25 Июля 2017 г. 13:51 + в цитатник
Просто — не значит примитивно. Мало — не значит непонятно. Вкратце можно выразить многое. Свободное пространство — не то же самое, что пустота. Сегодня мы поговорим о минимализме.


Как сказал в своей книге «The More of Less» Джошуа Бекер:

«Вам нужно не больше пустого пространства, а меньше всего остального».

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

Что такое минимализм?


Вообще, минимализм — это широкое понятие, которое употребляется в разных сферах человеческой деятельности. В словаре Merriam-Webster оно определяется как «стиль или техника (в музыке, литературе или дизайне), которые характеризуются крайне малым количеством элементов и простотой». К каким бы областям ни применялось понятие, оно сохраняет свои базовые отличительные свойства: простота и смысловая насыщенность.



Минимализм как направление в искусстве приобрело особенную популярность в Нью-Йорке в 1960е годы, когда художники и молодого, и старшего поколения стали склоняться к геометрически абстрактному стилю в живописи и скульптуре. Идеи этого движения нашли отражение в работах представителей школы Баухаус, общества Де Стейл, такого художественного направления, как конструктивизм, и так далее. Во многих сферах изобразительного искусства ключевой принцип минимализма состоит в том, чтобы оставлять только самые необходимые элементы, тем самым сосредоточивая внимание зрителя и создавая общее ощущение элегантности. Линии, фигуры, точки, цвета, пустое пространство, композиция — всё должно служить определенной цели и быть тщательно организовано. Сегодня мы можем встретить минималистичный подход в самых разных сферах жизни: архитектуре, живописи, фотографии, разных видов дизайна и даже сервировке еды.

«Форма, объем, цвет, поверхность — все это самостоятельные сущности. Не следует прятать их в составе существенно отличающегося целого. Формы и материалы не должны видоизменяться под влиянием контекста», — так сказал Дональд Джадд, американский художник, которого относят к минималистам. Дизайнеры, которые работают в этом стиле, стремятся сделать интерфейсы простыми, но насыщенными, стильными, но не перегруженными. Обычно они используют пустое пространство, цепляющие глаз цвета и сочетания шрифтов, а также многофункциональные детали, чтобы придать простоте элегантность. Перешагнуть черту между простым и примитивным очень просто. Именно поэтому многие дизайнеры не идут на риск и отказываются от этого стиля: кому-то он кажется слишком прилизанным, кто-то не может придумать, как выразить все необходимое малым числом элементов.



Блог об архитектуре

Характеристики минимализма


Основные черты, которые отмечают дизайнеры, говоря о минимализме, включают:

  • Простоту
  • Ясность
  • Выраженную визуальную иерархию
  • Большое внимание к пропорциям и композиции
  • Функциональность каждого элемента
  • Много пустого пространства
  • Меньше деталей и больше внимания к каждой
  • Типографику как важный элемент дизайна
  • Отказ от нефункциональных декоративных элементов

Конечно, этот список можно продолжать, но приведенных пунктов достаточно, чтобы сделать вывод: минимализм производит впечатление тренда, который делает интерфейсы удобнее для пользователя. Если применять его с умом, можно указать пользователю на самые значимые элементы и сделать его путь интуитивным и осмысленным. Кроме того, минималистичные интерфейсы обычно выглядят очень изысканно и аккуратно, доставляя смотрящему эстетическое удовольствие — а это один из самых ключевых факторов, которые привносят привлекательность в UX.


Лэндинг Dance Academy

Практики минимализма в цифровом дизайне


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

Плоский дизайн


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

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


Приложение Cafe Coupon

Палитра в оттенках серого или с минимумом цветов


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


Сайт Slopes

Яркая, выразительная типографика


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


Приложение Upper

Ограниченный выбор


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


Энциклопедия «Райские птицы»

Тематические визуальные элементы, притягивающие взгляд


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


Архитектурная компания

Лаконичная и интуитивная навигация


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

Свободное пространство


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


Сайт Ice

Сетки


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


The Big Landscape

Контрастность


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


Сайт Bjorn

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

Рекомендую к прочтению


Вот несколько статей, чтобы глубже ознакомиться с темой:

-> The Characteristics of Minimalism in Web Design
-> The How and Why of Minimalism
-> 6 Steps to Perfecting Minimalism in Web Design
-> Functional Minimalism for Web Design
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334058/


10 лет Школе анализа данных Яндекса

Вторник, 25 Июля 2017 г. 13:47 + в цитатник
Сегодня исполняется 10 лет Школе анализа данных Яндекса. Девять лет назад я в неё поступил, семь лет назад выпустился и в том же 2010 году, 21 июля, я стал сотрудником ООО «Яндекс».

С тех пор мы все сильно изменились: и я, и Яндекс, и ШАД. Но есть несколько уроков, которые я вынес из стен Школы, которые до сих пор оказываются для меня актуальными и вряд ли перестанут быть таковыми.




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

Ограниченность знания


Поступал я в Школу, только-только закончив третий курс кафедры прикладной математики МЭИ. Вообще-то тогда говорили, что создатели Школы рассчитывают на выпускников-бакалавров — то есть выпускников четвёртого курса. Так что я изрядно рисковал.

Комиссия собеседующих на устном экзамене впечатляла: Илья Борисович Мучник, maxim_babenko, Лена Бунина. Илья Борисович задавал мне вопросы по теории вероятностей, а затем и по математической статистике. И тут выяснилось, что статистики я совершенно не знаю, ведь её проходят на четвёртом курсе!

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

Затем я понял, что это ведь очень логично. Комиссия сразу смогла понять ограниченность моего знания; важно и то, что был понятный способ эту ограниченность преодолеть (перейти на четвёртый курс и всё узнать). Намного хуже не знать границы своего знания, чем просто чего-то не знать.


Максим Бабенко, Елена Бунина, Аркадий Волож, Илья Мучник и Григорий Кондаков

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

Интеллектуальная честность — это главное. И Илья Борисович был первым человеком, который меня этому научил.

Люди


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

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

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


Студенты ШАД в 2016 году

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

Любопытно было и то, что многие мои однокурсники в Школе являлись выпускниками мехмата или, например, кандидатами наук. Разумеется, с такими прекрасными людьми было бессмысленно состязаться в учёбе: они просто были лучше меня, и так продолжалось на протяжении всего времени обучения. Вот это уже оказалось совсем новым ощущением: учиться рядом с людьми, которые на голову тебя превосходят буквально во всех аспектах, и одновременно понимать, что всё нормально и, более того, классно.

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

Ещё один отличный эффект от такого соседства — понимание, что с задачей можно справиться. Ты непосредственно наблюдаешь людей, которые делают то же самое, но справляются. В итоге появляется надежда, что однажды справишься и ты.

Атмосфера


Когда молодые люди, уже и так совмещающие учёбу в вузе с работой, приходят в ШАД, чтобы посвящать еще три-четыре вечера в неделю (9–12 часов!) дополнительным занятиям, а кроме того, неизвестно сколько времени тратят на выполнение домашних заданий — это само по себе вызывает некоторое недоумение. Зачем им идти в ШАД? Они и без того учатся во в меру престижных вузах, которые, конечно же, дают им все необходимые знания и навыки для успешной будущей жизни и профессиональной деятельности, не так ли? А некие дополнительные знания — зачем они им? Это ведь лишняя трата сил на какие-то непонятные и никому не нужные дисциплины, которые практикующие программисты вообще никогда не применяют, разве нет?

Удивительно, но люди, приходящие в ШАД, настолько далеки от подобных мыслей, насколько вообще возможно. Их влечёт не какая-то непосредственная выгода от приобретаемых знаний; их влечёт Неизведанное.


Илья iseg Сегалович и Аркадий Волож на третьем выпускном ШАД

Как только мы задаём себе вопрос в духе «Зачем мне эта дисциплина, когда я и без неё прекрасно трудоустроюсь?», мы отказываем себе в возможности бесконечного развития, в счастье вечно быть в начале бесконечности; напротив, мы ограничиваем себя нелепыми рамками, которые в основном определяются степенью нашего нынешнего невежества.

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

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

Изменить мир может каждый


На выпускном Миша Левин сказал достаточно неожиданные для меня слова. Сейчас я не могу воспроизвести их в точности, но по сути Миша сказал следующее:

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

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


Михаил Левин, выпускник первого потока ШАД

Здесь есть два аспекта, на которых нужно остановиться.

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

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

Всё вышесказанное можно суммировать следующим образом. Для успешной жизни после учёбы человеку нужно не так уж и много:

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

Всё это даёт своим ученикам Школа. И все эти мысли очень ёмко выразил Миша своими словами: вы можете; идите и делайте!

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

https://habrahabr.ru/post/334066/


Метки:  

Эволюция атак на веб-приложения

Вторник, 25 Июля 2017 г. 13:37 + в цитатник

image


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


OWASP TOP 10


Классические уязвимости в данный момент представлены списком OWASP TOP 10:


  • A1 Внедрение кода
  • A2 Некорректная аутентификация и управление сессией
  • A3 Межсайтовый скриптинг
  • A4 Небезопасные прямые ссылки на объекты
  • A5 Небезопасная конфигурация
  • A6 Утечка чувствительных данных
  • A7 Отсутствие контроля доступа к функциональному уровню
  • A8 Подделка межсайтовых запросов
  • A9 Использование компонентов с известными уязвимостями
  • A10 Невалидированные редиректы

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


Хорошим примером выявления той или иной уязивмости можно считатать the unofficial HackerOne disclosure timeline: http://h1.nobbd.de/index.php. Как мы видим — приобладают SQL-инъекции, client-side атаки и т.д.


Типы атак


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


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


Нецелевые атаки, как правило, автоматизированы и выполняются с помощью различных систем эксплуатации: от сканеров уязвимостей, до самописных скриптов и утилит. Отличаются, как правило, несколькими признаками (User-Agent, вектор применения, диапазон IP). Например попытка выявления /uploadify/uploadify.php — уязвимости в модуле MODX.


Статистика нецелевых атак выглядит следующим образом:
Наиболее популярные атаки:


  • Попытки выявления SQL Injection: — 85%.
  • Попытки выявления доступа к критичным папкам и файлам: — 7%.
  • Попытки применения известных (нашумевших) эксплоитов — 5%.
  • Попытки внедрения выявления Cross-Site Scripting — 3%.

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


Эволюция атак


Эволюцию атак на веб-приложения можно рассматривать с нескольких ракурсов:


  • усложнение веб-приложений — как следствие больше возможностей ошибки;
  • усложнение архитектуры — как следствие больше возможностей ошибки;
  • популяризация «кулхакерства» — как следствие больше материала в открытом доступе, больше атак;
  • кажущаяся безнаказанность.

Этические рамки я оставлю вне этой статьи и хочу поговорить о технической стороне.


Появление новых векторов обусловлено использованием новых технологий либо выявлением уязвимостей в старых. Также, часть уязвимостей может оказаться "за бортом" и долгие годы не использоваться, как например XML External Entities: первые упоминания датируются 2002 годом, конкретизированные вектора 2009, массовая эксплуатация началась с 2011-2012 года практически повсеместно, например phpmyadmin. XXE уязвимости находили (в рамках BugBounty программ) на ресурсах Яндекс, Вконтакте, Uber и многих других.


Другим немаловажным фактором развития векторов атаки служат внедренные защитные средства. Мы установили уязвимое веб-приложение, указав тип уязвимости и защитили веб-приложение сервисом защиты: http://vulns.pentestit.ru.


http://vulns.pentestit.ru/wp-content/plugins/kittycatfish/base.css.php?kc_ad=31&ver=2.0"

Уязвимый параметр kc_ad. Атакующие в первую очередь пытаются выявить наличие инъекции с помощью символа кавычки, классика жанра:


Уязвимость на сайте присутствует, но проэксплутатироватть сходу ее не удастся, поэтому атакующие применяют техники тамперинга данных для попытки обхода защитных средств:


http://vulns.pentestit.ru/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+group%0aby%0a1%0aUNIO%6e%0aSELEC%74%0achar%0a(107,99,95,97,100,95,99,115,115),(selec%74%0acolumn_name%0afro%6d%0a`%69nformation%5fschem%61`.columns%0awher%65%0atable_name=0x746c5f746f6b656e%0alimit%0a0,1)

Такие методы обхода тоже не позволяют проэкспулатировать уязвимость, поэтому атакующие начинают использовать все более изощренные способы evasion-техник (о которых я писал в этой статье: методы обхода защитных средств веб-приложений при эксплуатации SQL-инъекций.


image


Это трансформируется в следующие запросы:


http://vulns.pentestit.ru/wp-content/plugins/kittycatfish-2.2/kittycatfish.js.php
Parameter kc_ad=%27%2F%2A%2A%2FanD%2F%2A%2A%2F3083%2F%2A%2A%2FbEtWEEN%2F%2A%2A%2F3083%2F%2A%2A%2FanD%2F%2A%2A%2F3083--%2F%2A%2A%2FiGqe&ver=2.0

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


Меры защиты


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

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

https://habrahabr.ru/post/334054/


Метки:  

Колибри для Фантома

Вторник, 25 Июля 2017 г. 13:32 + в цитатник
Краткое содержание: разработка модуля совместимости с ОС Колибри внутри модуля совместимости с ОС Юникс внутри ОС Фантомь)

Внутри ОС Фантом есть маленький простенький Юникс. POSIX подсистема. В принципе необязательная для работы самого Фантома и довольно неполная — Unix Quake под ней собрать удалось, а, например, апач не соберётся почти наверняка. Тем не менее — она есть.

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

Почему же, тем не менее, любопытно реализовать слой совместимости с этой ОС? Тому несколько причин:

  • Она очень компактна. Забегая вперёд — первую программу для Колибри в Фантоме удалось запустить через четыре часа работы.
  • Этот мини-проект стал драйвером развития некоторых нативных подсистем Фантома,
    в частности — оконной.
  • Главное — всё состояние процесса Колибри, известное ядру, укладывается в небольшую структуру. Многие (почти все!) вызовы — stateless, то есть не опираются о какое-либо знание,
    хранимое в ядре. Это идеальный кандидат на реализацию персистентных (переживающих перезапуск ОС) бинарных (не написанных на байткод-языке) процессов в Фантоме.

Для любопытных, код, хедер.

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

  • Загрузчик исполняемого образа
  • Точка входа в системный вызов
  • «Прокладки» для системных вызовов, конвертирующие их в семантику существующих компонент системы
  • Разработка недостающей функциональности

Загрузчик образа Колибри тривиален, за исключением реализации запуска запакованных программ. К сожалению, реализация распаковки по имеющимся фрагментарным спекам к успеху не привела, и найти кого-то, кто разбирается, не удалось. Непакованные программы устроены очень просто, так что детектирование и загрузка образа дополнили существующий elf-овский загрузчик без проблем. Кстати, под Фантом программы для Колибри можно компилировать и обычным elf-овским тулчейном — вне зависимости от того, какой загрузчик загрузил программу, она может обращаться и к системным вызовам POSIX, и к Колибри. Можно вперемешку )

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

Основная работа, конечно, это реализация системных вызовов. Работа трудоёмкая по двум причинам — во-первых, вызовы документированы схематично, во-вторых, их создатели реально не утруждали себя какой-либо консистентностью. Для примера — вызов запроса информации о процессе в одном из полей возвращает… номер другого процесса, окно которого находится в заданной z-позиции на экране.

Реализация вызовов делалась по принципу «типа TDD»: вместо реализации системного вызова просто пишем в лог ошибку, запускаем прикладные программы, если вызван не реализованный системный вызов, реализуем то, что было вызвано. Так что если колл не сделан, значит я не дошёл до прикладной программы, которая в нём нуждается.

В целом вызовы делятся на несколько групп.

Информационные


С ними всё просто. Ещё и потому, что часть информации можно выдать в константном или фейковом виде. Хороший пример — st->eax = dummy++; // TODO n of context switches — возрастает, и ладно. Где возможно, конечно, информация выдаётся реальная.

Low-level


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

Файловые операции


Файловые операции Колибри более-менее консистентны (как минимум, коды ошибок одни и те же), но реализация их весьма дорогостояща — все они не хранят в ядре практически никакого состояния и, де факто, сводятся к группе open / do / close. То есть, чтение из файла на каждый вызов выполняет открытие и закрытие файла. В принципе, это можно попробовать оптимизировать через hash map имени файла и держать пул открытых дескрипторов, но в скоуп проекта выходного дня это уже не входит. Я не делал. В остальном реализация более-менее тривиальна.

Графика


Тут я ожидал проблем. Они и были, но, в основном не столь жуткие, как могло бы случиться. Впрочем, есть ощущение, что представления авторов графической подсистемы Колибри до конца я всё равно не постиг — некоторые программы работают нормально, некоторые — странно. Увы, без того, чтобы реально читать исходники оригинальной реализации, наверное, прогресс тут невозможен, а исходники, я напомню, на ассемблере. Я не нашёл в себе достаточно куража, и остановился на том, что какое-то подмножество программ работает нормально.

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

Реализовано, но не протестировано


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

Отсутствует


Полностью не реализованы функции управления отображением памяти — в настоящее время ядро Фантома работает только с одним адресным пространством (процессы Юникса и Колибри поддерживаются через механизм сегментной адресации x86), поэтому их не на что отображать. В силу этого же факта трудно (хотя и можно) реализовать изменение размера адресного пространства процесса. Не реализована поддержка DLL -сама Колибри ими пользуется очень неактивно, а план был в том, чтобы сделать минимум необходимого. Впрочем, это не представляется сложным.

Развитие проекта


Довольно очевидно, что для продолжения работ требуется:

  • Набор регресс-тестов. Желательно в виде а) внутренних юнит-тестов для компонент;
    б) специальных тестовых прикладных программ и в) прогона существующих программ с контролем их работоспособности.
  • Ревью кода опытным разработчиком ядра Колибри на предмет соответствия реализации оригиналу
  • Ревью кода на предмет подробной верификации всех точек входа Колибри-Фантом на предмет допустимости и осмысленности параметров.

В общем, нужен герой из команды разработчиков ОС Колибри. I need a hero :)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333982/


Метки:  

[Из песочницы] CRM уже не спасет: что делать, когда бизнес перерос «коробку»

Вторник, 25 Июля 2017 г. 12:58 + в цитатник
Идея для бизнеса рождается в голове, улетая в блокнот, — и после в Excel: где, как правило, начинается первая работа с данными.

Переход на новый этап происходит в момент, когда со старыми инструментами (Excel или Acess) случился завал — когда неэффективность бизнес-процессов приводит к потерям. Однажды, работа с таблицами заведет в тупик — информации будет слишком много: возникнут проблемы с поиском, ведением клиентов, — тогда бизнес уходит в CRM-систему.

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

Ниже разберемся с тем — что делать если «коробки» недостаточно, и как автоматизировать более сложные бизнес-процессы, чем редактирование карточки клиента.


image



Чего не хватает в коробках


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

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

Итак, в целом понятно, что основной недостаток закрытых CRM — это невозможность адаптировать ее конкретно под ваш бизнес. Даже если на начальном этапе ваши задачи полностью решались в такой системе — с ростом предприятия возникнут проблемы: п1, п2 и п3



image



Решаем проблемы с помощью платформы


Прежде чем решать вопросы с автоматизацией, — надо определиться с платформой, которая подойдет конкретно вам.

Ниже рассмотрим несколько известных вендоров:


CRM Salesforce


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

Для разработки Salesforce использует язык Apex, а работает исключительно по модели SaaS. Проектирование осуществляется на базе их собственного средства: Visualforce.

Еще у них есть Data.com — облачная СУБД, которая подойдет для своих приложений или проектов, не привязанных к системе. Реализовано неплохое решение для работы над дизайном интерфейсов — Lightning Components, с ним можно создать интерфейс и логику web-приложения при помощи CSS, HTML, и JavaScript. От тарифа зависят возможности по доработке и количеству таблиц на пользователя, доступ и прочее.

Salesforce — довольно дорогая система; если вы примите решение о её внедрении, стоит просчитать затраты на доработку или заработную плату штатного программиста. Однако, это не единственное решение: есть российские варианты, которые более адаптированы к нашей отчётности и интеграциям с учетными системами.


CRM Terrasoft


Terrasoft дает клиентам альтернативу в виде двух типов платформ: первая — для разработки на десктоп (Terrasoft 3.X ), и bpm'online — для веб-приложений.

В первом случае, с десктопной платформой можно создать модули и конфигурации, изменять функциональность. Terrasoft IDE 3.X имеет средства для визуальной разработки, а также конструктор запросов к БД, конструктор отчетов, окон и прочего. Все эти элементы конфигурации хранятся в СУБД, и юзеру показывают лишь часть изменившихся мета-данных.

Приложения могут разворачиваться под управлением СУБД MS SQL Server, Oracle или Firebird, поддерживается SSL для web-сервисов. С помощью Tearrasoft 3.X можно строить интеграции со сторонними приложениями.

Terrasoft — одна из самых дорогих российских CRM-систем. К тому же, платформа доступна лишь тем, кто уже приобрёл лицензии. Однако преимущество Terrasoft — в удобстве использования платформы.


Клиент-Коммуникатор («Системы КлиК»)


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

Для доработки web-версии КлиК использует дизайнер форм, который позволяет создавать решения от простых таблиц, связанных с базой данных системы до web-приложений. Пользователи как конфигураций для ОС Windows, так и для web работают в единой базе on-line. В принципе, решение очень неплохое и требует довольно стандартных знаний (не придётся сильно переплачивать за уникальные скиллы нанимаемого специалиста), но при этом косное с точки зрения используемых технологий.

КлиК хорош тем, что предоставляет самые широкие возможности кастомизации и при этот требует от пользователя владения стандартными скиллами. Из недостатков — зацикленность на технологиях Microsoft, использование тяжеловесной СУБД MS SQL.

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

Все это — лишь одни из самых популярных вендоров. При тщательном подходе к выбору можно найти для себя самый подходящий вариант.


Принципы, по которым будем настраивать и внедрять CRM


image


Чтобы настроить свою систему — необходимо следовать базовым принципам. Рассмотрим некоторые шаги:

1. Первое, с чем предстоит разобраться — это выбрать самые основные бизнес-процессы, и формализовать их; то есть прописать последовательность действий: вход, выход, метрики (KPI) процесса.

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

3. Создаем концепцию проекта. На этом этапе мы четко прописываем цели внедрения CRM. От целей будут идти все прочие детали: то, какими должны быть личные кабинеты, функциональные модули и прочее. Далее определяемся с параметрами проекта — это бюджет, сроки, выбор подрядчика.

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

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

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


Сколько все это будет стоить?


image


Как правило, полная стоимость CRM-систем состоит из несколько частей:

  • Стоимость лицензии (приобретения). Это может быть оплата доступа или стоимость одной копии на рабочее место.

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

  • Стоимость доработки. Даже если вы полностью настроили систему — доработок не избежать: в самом начале, по мере работы некоторые процессы будут меняться на более эффективные, поэтому важно учитывать такие затраты.

  • Стоимость сопровождения

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

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

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

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


Стоимость лицензии

В зависимости от того, какую CRM вы выбрали, возможны различные варианты покупки лицензии. Вы можете:

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

Заключение


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

Поэтому для бизнеса, в котором есть потенциал к росту во что-то большое и сложное — есть смысл еще в начале своего развития настраивать ту систему, которая всегда будет четко откалибрована под необходимые процессы. Система, которая растет вместе с бизнесом, и всегда соответствует его потребностям.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334070/


Метки:  

[Перевод] Выпуск Rust 1.19

Вторник, 25 Июля 2017 г. 12:29 + в цитатник

Команда Rust рада представить выпуск Rust 1.19. Rust — это системный язык программирования, нацеленный на скорость, безопасность и параллельное выполнение кода.


Если у вас установлена предыдущая версия Rust, для обновления достаточно выполнить:


$ rustup update stable

Если же Rust еще не установлен, вы можете установить rustup с соответствующей страницы нашего веб-сайта и ознакомится с подробными примечаниями к выпуску Rust 1.19 на GitHub.


Что вошло в стабильную версию 1.19.0


В Rust 1.19.0 вошли некоторые долгожданные функции, но для начала, замечание для пользователей Windows. На этой ОС Rust использует для сборки link.exe, который входит в состав "Microsoft Visual C++ Build Tools". В последнем выпуске Visual Studio 2017 структура директорий для этих инструментов изменилась. Из-за этого вы были вынуждены использовать инструменты версии 2015 или изменять переменные среды (например, запуская vcvars.bat). В Rust 1.19.0, rustc знает, как найти инструменты версии 2017, поэтому вам не потребуется более использовать обходные пути.


А теперь к новым возможностям! Rust 1.19.0 — это первый выпуск, поддерживающий union (Объединения):


union MyUnion {
    f1: u32,
    f2: f32,
}

Объединения похожи на enum (Перечисления), но они не имеют "меток" в отличие от последних. "Метка" в enum позволяет узнать во время исполнения, какой вариант из перечисленных хранится в переменной.


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


let u = MyUnion { f1: 1 };

unsafe { u.f1 = 5 };

let value = unsafe { u.f1 };

Сравнение с образцом (Pattern matching) также работает:


fn f(u: MyUnion) {
    unsafe {
        match u {
            MyUnion { f1: 10 } => { println!("десять"); }
            MyUnion { f2 } => { println!("{}", f2); }
        }
    }
}

Когда объединения полезны? Главная сфера применения — взаимодействие с C. C API могут (и часто делают это) предоставлять объединения, так что написание оберток для API значительно упрощается. Также, из данного RFC:


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

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


К слову, а вы когда-нибудь интересовались, как новые возможности добавляются в Rust? Объединения были предложены Josh Triplett, и он выступил на RustConf 2016, рассказав про процесс интеграции. Вы должны на это взглянуть!

К другим новостям, loop теперь могут возвращать значения через break:


// старый код
let x;

loop {
    x = 7;
    break;
}

// новый код
let x = loop { break 7; };

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


Что насчет остальных циклов? Еще не ясно, смотрите обсуждение в этом RFC.


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


let f: fn(i32) -> i32 = |x| x + 1;

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


Компилятор теперь может запускаться на Android. Мы долгое время всячески поддерживали разработку на Android и наша поддержка продолжает улучшаться.


В заключение, о совместимости. Ранее, когда мы двигались к Rust 1.0, мы проделали большую работу, чтобы убедиться в том, что все отмечено как "стабильное" и "не стабильное". Однако мы просмотрели одну вещь: -Z флаги. -Z флаг компилятора включает нестабильные флаги. В отличие от всего остального, вы можете использовать -Z со стабильным Rust. В апреле 2016, в Rust 1.8, мы добавили предупреждение при использовании -Z со стабильной и бета версиями Rust. Более чем год спустя, мы починили эту дыру в нашей истории стабильности, запретив -Z везде, кроме ночных сборок компилятора.


Смотрите детальные заметки к выпуску для подробностей.


Стабилизация стандартной библиотеки


Крупнейшие изменения в стандартной библиотеке — макросы eprint! и eprintln!. Они работают точно так же, как print! и println!, но пишут в стандартный вывод ошибок, а не в стандартный вывод.


Другие изменения:



И некоторые стабилизированные API:



Смотрите детальные заметки к выпуску для подробностей.


Улучшения Cargo


В этом выпуске в Cargo были добавлены небольшие, но важные улучшения. Крупнейшее из них: Cargo теперь работает непосредственно с git-объектами. Это уменьшает размер реестра и ускоряет клонирование, особенно на Windows.


Другие улучшения:



Смотрите детальные заметки к выпуску для подробностей.


Разработчики 1.19.0


Множество людей участвовало в разработке Rust 1.19. Мы не смогли бы этого добиться без участия каждого из вас. Спасибо!


От переводчика
Благодарю ozkriff и gordon-f за помощь в переводе

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

https://habrahabr.ru/post/334068/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1064 1063 [1062] 1061 1060 ..
.. 1 Календарь