IT BM
Поговорим о быстром выводе продукта на рынок. Какими средствами можно добиться времени создания рабочего прототипа не самого простого сервиса в течение фантастических 1-2 недель силами одного-двух человек. Плюс немного размышлений о внутренних стартапах, предпосылках быстрого прототипирования и смысле проверки гипотез перед продажей продукта на инвестиционных комитетах.
Как работает книжный бизнес сейчас и насколько реально простому айтишнику выпустить книгу, не имея подписчиков и статуса медийной личности?
Сегодня — и после долгого перерыва — поговорим, наконец, о шансах на интерес к вам со стороны издательств, опасных договорах и этапах создания книги с профессионалами книжного рынка. Прошу:
Можно ли прожить IT-шнику без привычных зарплат, а подавшись, скажем, в авторы? Материалы для разработчиков востребованы, да и зарабатывать своим хобби — чем не мечта.
С другой стороны, все мы откуда-то слышали, что писатели — Пелевина не берем — получают копейки.
Так ли это на сегодняшний день, сколько донатят за выложенные бесплатно книги, окупается ли реклама самиздатных книг и сколько платят авторам крупные издательства? Сегодня заключительная часть нашего путешествия в мир современного книжного дела.
Всем доброго времени суток. Сегодня хочу рассказать максимум о регулярных выражениях: что они из себя представляют, как их писать, для чего нужны и т.д.
Информации о регулярках много, они разбросаны по разным сайтам и я решил собрать всё, касательно регулярок, в одну статью. Ну что-ж, приступим поскорее к делу.
Тот, кто научится правильно измерять продуктивность разработчиков, точно станет миллионером. Особенно на текущем рынке труда, где кандидаты просто называют случайные пятизначные числа желаемой зарплаты. Есть несколько вендорских платных решений, но они не получили распространения. Никто не ставит такую систему по умолчанию, как, например, CI/CD. Давайте посмотрим на возможные подходы к измерению продуктивности и поговорим об этом в комментариях.
Небольшая подборка веществ помогающих нашим мозгам работать чуточку лучше. Большинство из них продается в ближайшей аптеке, отпускается без рецепта, имеют доказательную базу и плюс-минус универсальны, так как «качают» самое важное — мотивацию, энергию и память.
Читать на английском – интересно и полезно. Однако, многолетнему обитателю рунета непросто найти хорошие иностранные ресурсы. Плюс, многое из найденного оказывается скучным или слишком сложным. Я постарался подобрать интересные сайты для практики английского и понять, какие из них имеют доступный уровень сложности, а какие – более 9999999.
На выходе получился список сайтов размеченных по уровню сложности: легко, средне, сложно, очень сложно. Список разбит на 6 форматов: расшифровки подкастов, интервью, площадки для общения, новости и статьи, книги, обучающие тексты.
Разработка и поставка продукта является смысловой конструкцией, которая характеризует наличие, понимание, использование инженерных подходов и инструментов для разработки программного обеспечения. Активное использование инженерных практик позволяет выпускать продукт высокого качества инкрементно и итеративно, соответствующего потребностям стейкхолдеров.
В данной статье предложена система метрик для измерения и дальнейшего анализа атрибутов организации разработки и поставки программного продукта.
Для своего телеграм-канала я время от времени пишу конспекты интересных мне деловых книг. Одна из них — «Откуда берутся хорошие идеи» Стивена Джонсона. Тираж книги на русском закончился еще в 2014 году, купить можно только на английском языке.
Стивен Джонсон (Steven Johnson) — известный американский ученый и писатель, автор двенадцати книг о взаимодействии науки, техники и человеческого опыта, в том числе, бестселлера «Нет худа без добра: как современная массовая культура делает нас умнее».
Последние десять лет Джонсон изучает историю инноваций. Результаты его исследований и легли в основу бестселлера «Откуда берутся хорошие идеи». Стивен создал несколько сайтов, в том числе, «Магазин исчезнувшей еды», Plastic.com.
Главная сложность в разработке приложения – накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.
С тех пор я запустил три приложения руками разработчиков и ещё одно собственноручно. Не бог весть какой опыт, но иллюзий поубавилось. А реализация функционала видится мне теперь самой простой и прогнозируемой задачей из всех.
Хочу поделиться краткой выжимкой из своего опыта: какие неожиданные сложности вас ждут, если вы делаете мобильное приложение впервые.
"Шеф, всё пропало, у нас serial на мегатаблице кончился!" - а это значит, что либо вы его неаккуратно накрутили сами, либо у вас действительно данных столько, что разрядности integer-столбца уже не хватает для вашей большой и активной таблицы в PostgreSQL-базе.
Да и столбец этот не простой, а целый PRIMARY KEY, на который еще и ряд других немаленьких таблиц по FOREIGN KEY завязан. А еще и приложение останавливать совсем не хочется, ибо клиентам 24x7 обещано...
В общем, надо как-то с минимальными блокировками увеличить размер PK-поля в большой таблице, на которое многое завязано.
Давным-давно (лет пятнадцать назад) почти все делали сайты и не переживали о том, что под капотом. Верстали таблицами, использовали всё, что попадётся под руку (а попадались в основном <div> и <span>) и не особо заморачивались о доступности. А потом случился HTML5 и понеслось.
Семантическая вёрстка — подход к разметке, который опирается не на внешний вид сайта, а на то, какой смысл у каждого блока на конкретной странице. Например, в этой статье есть заголовки разных уровней — это помогает читателю выстроить в голове структуру документа. Так и на странице сайта — только читатели будут немного другими.
Дисклеймер: статья может обидеть тех, кто прикипел к вёрстке дивами. Но <div> — не приговор, и мы не призываем от него целиком отказываться. Ну и всегда можно договориться.
Правила. Мы знаем это слово с самого детства. Сначала родители учат нас, как нужно правильно поступать, потом мы приходим в школу, где учителя диктуют свои порядки. В университете мы вновь сталкиваемся с правилами, которые для нас устанавливают преподаватели и деканат. По мере взросления мы начинаем следовать законам, которые разработаны государством. Что общего у всех этих правил? То, что они выверены годами, десятилетиями, а некоторые даже и поколениями. Представьте, какой была бы наша жизнь, если бы правила менялись часто: каждую неделю или каждый день!
Мне самому не верится в то, что я сейчас пишу. Еще только пять лет назад я жил в небольшом провинциальном городе Пенза и работал программистом в среднего размера геймдев-компании за очень небольшие деньги. Жил я так сказать не тужил - я потихоньку работал, учился, строил какие-то планы, но особых амбиций не имел, а плыл так сказать по течению. Пока одним холодным осенним вечером не познакомился с человеком, навсегда изменившим мою жизнь.
Он был на несколько лет старше меня и тоже работал программистом, но в отличии от меня он работал на западных заказчиков и получал за свою работу гораздо больше, чем я. Но это было не главное, что меня поразило - впервые я встретил человека, который был настолько активен, столько всего знал и занимался сразу кучей интереснейших проектов. К счастью для меня, он с радостью поделился со мной секретами своей продуктивности, которые оказались совсем не секретами, а информацией, которой просто переполнен интернет. Так я познакомился с миром инструментов и техник личной эффективности.
Это дало мне сильнейший толчок и изменило мою жизнь до неузнаваемости. За прошедшие пять лет я попутешествовал по куче стран, полтора года прожил в солнечной Черногории, переехал в Израиль, несколько раз менял работу на компании с гораздо лучшими условиями, в последний раз устроившись на работу, на которой мой доход в более чем 15 раз превышает мой доход пять лет назад, и на которой я делаю продукты для всемирно известных корпораций и организаций, создал три более-менее успешных open-source проекта на Github и написал множество статей на Хабрахабр, некоторые из которых имели ошеломительный успех у читателей.
В течение этих пяти лет я перепробовал множество техник и инструментов личной продуктивности. Какие-то из них работали плохо, какие-то оказались весьма эффективными. Я собрал все зарекомендовавшие себя методы в единый фреймворк, помогающий мне определять свои желания и направления для развития, ставить четкие цели, разбивать путь к ним на отдельные шаги и достигать их. Этим самым фреймворком я и хочу с вами поделиться.
Для кого-то этот пост может показаться сборником давно знакомых инструментов, а кто-то найдет здесь кладезь полезной информации. Ну что ж, поехали...
Известно, что разработчики облачных систем нередко работают в условиях сильного давления, когда сроки поджимают и выдавать результат нужно быстро. В силу этого зачастую они не уделяют должного внимания написанию кода и конфигурации. А отсутствие надлежащих конфигураций является источником брешей в системе безопасности. Из этого следует, что в ходе всего процесса разработки архитектуры обязательно нужно полагаться на передовые методы проектирования, даже если сроки очень сжатые.
Теперь давайте разберем реальный пример того, как можно автоматически проконтролировать корректность методов разработки в конвейерах IaC для среды AWS посредством сотен проверок на соответствие правилам AWS Well-Architected Framework (безопасность, оптимизация затрат, производительность, высокие стандарты профессиональной деятельности и надежность) и другим стандартам.
