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

В статье описаны проблемы при проектировании баз данных и немного всего приложения, которые потом с ростом проекта все сложнее и сложнее решить. Моменты, которые важно учесть на этапе дизайна, и не задумываться о них в последствии. Ну или задумываться за чашкой чая и фразой «А помнишь, как мы решили это сделать сразу? Сколько времени мы этим себе сэкономили!», а не с ощущением зубной боли и болезненном вздрагивании при каждом воспоминании. По мере роста системы и числа пользователей, дизайн базы все сложнее и сложнее изменить, и масштаб изменений становится все более глобальным и трудоемким.

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

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

История первая

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


Игровая компания немца разрабатывала 3 вида игр:

1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
3. Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

Добрый день, друзья! Захотелось мне изучить react native под Windows7 64. На мою беду, у меня процессор AMD, который не поддерживает VT-x or SVM.



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

Вот интересная демонстрация возможностей afl; меня реально удивило, что она работает!

$ mkdir in_dir
$ echo 'hello' >in_dir/hello
$ ./afl-fuzz -i in_dir -o out_dir ./jpeg-9a/djpeg

В сущности, я создал текстовый файл только со словом "hello" и попросил фаззер выдавать поток в программу, которая ожидает на входе изображение JPEG (djpeg это простая утилита, которая идёт вместе с распространённой графической библиотекой IJG jpeg; libjpeg-turbo тоже должна подойти). Конечно, мои входные данные не похожи на валидное изображение, так что утилита быстро отвергает их:

$ ./djpeg '../out_dir/queue/id:000000,orig:hello'
Not a JPEG file: starts with 0x68 0x65

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

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

• Я написал вопрос по ссылке {здесь}. Могли бы вы исправить ошибку?
• Привет, пожалуйста, помогите здесь {ссылка}.
• У меня есть серьёзное домашнее задание со сроком сдачи сегодня в 5 вечера, и мне с ним не справиться. Могли бы вы скачать его здесь {ссылка} и сделать так, чтобы к тому времени оно работало?

Это полные тексты реальных электронных писем, которые я нередко получаю.

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

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

Здравствуйте!

Спойлер: не совсем умер, но цитата уж больно подходящая.

Этот пост подведение итогов и планы на будущее. Краткая предыстория: пользуясь современной терминологией, «Свезёт» задумывался как match making'овый (тогда назывался «краудсорсинговый») проект, позволяющий удаленно купить и привезти нужный Вам товар. Акцент был именно на купить и привезти потому, что доставка любых вещей хоть и более жизненная, но потенциально более опасная для перевозчиков. А в случае с покупкой (если она совершается не «в лавке на заднем дворе улицы XXX по паролю YYY») опасностей гораздо меньше.

Время показало, что спрос на покупку и доставку есть, а вот на доставку гораздо меньше (близкий к 0). Ну и если было понятно, куда делать pivot: в витрину импортных товаров, как сделали тогдашние конкуренты gransjoy и новый стартап grabr.io (вроде как привлекли $4M) то понимания как убедить перевозчиков участвовать на тот момент не было. страна переживала «тучные годы», и небольшие суммы не привлекали их, а бОльшие делали покупку не выгодной.
О сути заголовка я напишу по катом.

Друзья, вновь пришло время авторской колонки корпоративного блога PG Day’17. Предлагаем вашему вниманию сравнительный анализ работы с PostgreSQL из популярных ORM от varanio.

ORM (Object-Relational Mapping), по идее, должен избавить нас от написания SQL запросов и, в идеале, вообще абстрагировать от базы данных (от способа хранения данных), чтобы мы могли работать с классами, в той или иной степени выражающими объекты бизнес-логики, не задаваясь вопросом, в каких таблицах всё это по факту лежит.

Посмотрим, насколько это удается современным библиотекам на PHP. Давайте рассмотрим несколько типичных кейсов и сравним ORM с голым SQL, написанным вручную.

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

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

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

У вас есть возможность меньше чем за сутки получить обратную связь живых пользователей, и вы потратите всего 75$.

Муха дрозофила. Источник

Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.

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

Dummy Origin – это тот инструмент, который позволяет сделать все это наилучшим образом, а главное – легко.

Привет, Хаброжители! Наконец-то у нас вышла книга Дженнифер Дэвис и Кэтрин Дэниелс — Философия DevOps.

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

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

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

Avito развивался стремительно с первых дней. Например, скорость загрузки новых картинок для объявлений выросла в первые годы в несколько раз. Это требовало от нас на начальном этапе решать вопросы, связанные с архитектурой, максимально оперативно и эффективно, в условиях ограниченных ресурсов. Кроме того, мы всегда отдавали предпочтение простым решениям, требующим мало ресурсов на поддержку. Принцип KISS («Keep it short and simple») — это до сих пор одна из ценностей нашей компании.

Перевод статьи Scott Arciszewski «A Gentle Introduction to Application Security».

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

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

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

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

Я был недоверчив, когда прочитал это наблюдение у Реджинальда Брейтуэйт:

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

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

Роман Шелехов, руководитель группы развития корпоративных электронных каналов в Банке ВТБ и магистр Гильдии вольных проектировщиков, специально для «Нетологии» адаптировал статью Grzegorz Oksiuta об адаптации пользователя как об одном из важнейших элементов приложений.

Адаптация пользователя (Onboarding/Онбординг) – ключевой элемент любого приложения. Зачастую именно простота использования определяет, будут ли пользоваться приложением или нет.

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