Пока дизайнеры продолжают испытывать восторг от появления возможности прототипирования в двух известных инструментах, анонсированных в один день; мир независимых разработчиков продолжает выпускать всякие нужные инструменты. В 9-м выпуске 20 ссылок
Читать полностью »
Мы, Smart Engines, продолжаем цикл статей про то, как встроить наши технологии распознавания (паспортов, банковских карт и других) в ваши приложения. Ранее мы уже писали про встраивание на iOS и Android, а сегодня мы расскажем про то, как работать с Python-интерфейсом библиотеки распознавания Smart IDReader и напишем простого Telegram-бота.
Кстати, список поддерживаемых нами языков программирования расширился и теперь включает C++, C, C#, Objective-C, Swift, Java, Python, а также такие эзотерические языки, как Visual Basic и, разумеется, PHP. Как и раньше, мы поддерживаем все популярные и многие непопулярные операционные системы и архитектуры, а наши бесплатные приложения доступны для скачивания из App Store и Google Play.
По традиции, демо-версия Smart IDReader SDK для Python вместе с исходным кодом реализации Telegram-бота выложены на Github и доступны по ссылке.
Сегодня React — одна из самых популярных в мире библиотек JavaScript для пользовательского интерфейса: более 70 тыс. «звезд» на Гитхабе, не менее 1100 авторов и миллионы скачиваний каждый месяц — кроме того, этот фреймворк используется более чем в 4 тыс. компаний. Но когда Фейсбук впервые показал React миру, это мало кого обрадовало.
Мы решили погрузиться в историю рождения одной из самых популярных технологий в мире разработки ПО — React, и пригласили Пита Ханта (Pete Hunt), стоявшего у истоков этой библиотеки (сейчас он генеральный директор компании Smyte), чтобы он наконец-то рассказал о том, для чего создавали React, почему эта технология стала популярной в Фейсбуке после приобретения Инстаграма, и как она в итоге вышла в люди.
Марк (Цукерберг) собрал всех и говорит: «Мобильные устройства «выстрелят», поэтому срочно бросаем всё и переводим ресурсы на мобильные разработки». Мне казалось, это какая-то сумасшедшая идея: мы не могли поддерживать работу самого большого фотосайта в сети, имея горстку людей в команде. Совершенно бессмысленно переводить людей на разработку приложений для iOS и Android, которые составляют совсем небольшую долю нашего трафика. Но оказалось, что Марк был на 100% прав — поэтому я и не генеральный директор Фейсбука…
Мы разработали приложение Facebook Camera, и даже гордились тем, что получилось… Но пришел Инстаграм — и наш проект канул в Лету…
Ребятам из Инстаграма дали гараж на территории Фейсбука, где можно было сидеть и спокойно пилить свою идею. Они пользовались надежными системами безопасности Фейсбука, но кроме того продолжали использовать AWS, а еще — разрабатывали собственную стратегию продукта, насколько я могу судить… И я был первым сотрудником из Фейсбука, которого перевели в Инстаграм…
Переведено в AlconostЧитать полностью »
Вы, наверное, никогда не слышали о недавно умершем Джиме Вайрихе [Jim Weirich] или его программах. Но вы почти наверняка пользовались приложениями, построенными на основе его работы.
Вайрих помог создать несколько ключевых инструментов для Ruby, популярного языка программирования, код на котором написан для таких сайтов, как Hulu, Kickstarter, Twitter, и огромного числа других. Исходники его кода были открытыми, что означает, что использовать и изменять их могли все желающие. «Он был плодовитым членом западного сообщества Ruby», — говорит Джастин Сёрлс [Justin Searls], разработчик Ruby и сооснователь компании, разрабатывающей ПО, Test Double.
Когда Вайрих умер в 2014-м, Сёрлс заметил, что уже никто не поддерживает один из инструментов Вайриха для проверки софта. Это означало, что никто не будет одобрять изменения, если другие разработчики пришлют в проект исправления багов, патчи для безопасности или другие улучшения. Любые тесты, основывающиеся на этом инструменте, в итоге будут проваливаться, поскольку код устареет и станет несовместимым с новыми технологиями.
Читать полностью »
Платформа для разработчиков запустила функцию под названием Dependency Graph, которая оповещает разработчиков в том случае, если их код содержит известные уязвимости. Система анализирует зависимости и модули, использующиеся в проекте, и выводит информацию о содержащихся в них ошибках безопасности. Инициатива направлена на повышение уровня безопасности проектов с открытым исходным кодом.Читать полностью »
В этой статье я расскажу о том, как настраивал непрерывную интеграцию в Amazon AWS для репозитория DevExtreme.
Уже несколько месяцев мы ведём разработку DevExtreme в открытом репозитории на GitHub. Непрерывная интеграция у нас с самого начала была построена на базе Docker, чтобы не зависеть от CI-платформы (будь то Travis, Shippable или что-то другое), но с момента публикации репозитория мы не выделялись и использовали для прогона тестов хорошо знакомый Travis CI. На GitHub у нас "бегает" только небольшая часть автоматических тестов, так сказать, первая линия, и возможностей Travis для техники Fork and Pull Request хватало.
Со временем коллеги начали сетовать на очередь из пулл-реквестов (но терпели). Мысль о том, что пора уже что-то предпринять, возникла в конце октября, когда на два дня Travis потерял связь с Docker Hub, а мы как раз готовились к beta-релизу DevExtreme 17.2.
Получив добро на эксперименты в корпоративном AWS-аккаунте, я решил дать второй шанс проекту Drone. Почему второй? Потому что мы его уже пробовали в процессе "обкатки выхода на GitHub". Тогда наш репозиторий был приватным, Drone был ещё более сырым, чем сегодня, и запускали мы его на временной наколеночной инфраструктуре, точнее на старых рабочих станциях, оставшихся после апгрейда рабочих мест (наш IT-отдел обещал их вот-вот забрать, но не торопился).
Недавно мы запустили новый проект под названием Froala Design Blocks. Через несколько дней мы попали в список самых популярных репозиториев GitHub. Спустя неделю мы набрали 3500 звезд и в течении следующих двух стабильно собирали еще по 500 в сутки.
В отличие от Twitter или Facebook, где можно набрать подписчиков или лайки через рекламные схемы, на GitHub звезды вам ставят только те, на кого ваш проект действительно произвел впечатление. Поэтому их число о многом говорит — это надежный показатель, который пробуждает доверие и влияет на решение людей, когда они думают, стоит ли пробовать продукт.
Froala Design Blocks — не первый наш продукт, мы на GitHub уже несколько лет. Но я только недавно стала осознавать ценность звезд и вникать, каких правил нужно придерживаться, чтобы люди их ставили. Так что надеюсь, и новички, и ветераны найдут здесь что-нибудь новое для себя о том, как в полной мере использовать потенциал звезд для представления и усовершенствования своего проекта.
Читать полностью »
В разделе trending на GitHub отображается список проектов, активно набирающих звезды в течение дня, недели или месяца. Все самое интересное, что появляется в open source для каждого языка программирования, всегда оказывается в этом списке. Сегодня хочу поделиться способом, как с помощью GitHub уведомлений подписаться на появление новых «звездных» проектов и не пропустить что-нибудь полезное для себя.
Читать полностью »
Задумывались ли вы, что перед биологами, помимо всего прочего стоит ряд важных задач? Им необходимо анализировать огромные объёмы информации для отслеживания динамики популяции, выявления редких видов и оценки воздействия. Под катом мы хотим рассказать вам о проекте по идентификации красноногих моевок на фотографиях, сделанных с помощью камер слежения. Вы узнаете подробности о разметке данных, обучении модели на платформе Azure Machine Learning Workbench с использованием Microsoft Cognitive Toolkit (CNTK) и Tensorflow, а также развертывание веб-службы прогнозирования.
При разработке документации мы руководствуемся не только стандартами, но и удобством её использования. Стандарты определяют состав и форму документации, а формат строится исходя из удобства. Разработчик Сергей Бочаров рассказывает о пути Markdown-документа и о проблемах, которые приходится решать в обмен на простоту использования этого формата.
У меня иногда складывается впечатление, что не он служит для нас, а мы служим для этого формата. Поэтому — сэр Markdown.
