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

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

В этом посте я расскажу о новой и (как мне кажется) относительно малоизвестной фиче C++ - reference-qualified member functions. Расскажу о правилах перегрузки таких функций, а также, в качестве примера использования, расскажу, как с помощью ref-qualified функций можно попытаться улучшить схему управления ресурсами, реализуемую с помощью другой идиомы С++ — RAII.

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

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

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

Всем привет!

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

Я тоже не идеальна, так что добавлю картинку со случаем из моей жизни:

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

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

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



Сохраните следующую программу в /tmp/quine.pl

Illegal division by zero at /tmp/quine.pl line 1.

Запустите её командой

perl /tmp/quine.pl

и она выведет свой собственный код.

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

  File "quine.py", line 1
    File "quine.py", line 1
   ^
IndentationError: unexpected indent

Но перловый квайн в начале этой заметки — это обманка совершенно другого рода — программа разбирается корректно.

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

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

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

Любой веб-разработчик, который занимается этим хотя бы несколько лет, наверняка день за днем слышит подобный вопрос:

Я действительно хочу стать веб-разработчиком, но я не знаю с чего начать. Есть какие-то предложения?

Лет 10 назад ответ был очень прост. Просто создайте index.html, добавьте туда несколько тегов, сделайте заголовок красным с помощью CSS и подключите JQuery для обработки кликов!

Ох, как же все изменилось. Теперь мы работаем с инструментами сборки, маршрутизацией на стороне клиента, специальными фреймворками с причудливым рантаймом, привязывая везде «this», шаблонными литералами, CSS-in-JS… как же выбрать то, что важнее всего?

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


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

Согласно рейтингу TIOBE в 2018 году VB.NET обогнал по популярности C#. Совпадение или нет, но в феврале Эрик Липперт, один из создателей C#, призвал читателей обратить внимание на блог его друга, бывшего коллеги по команде компилятора Roslyn и, по совместительству, ярого фаната VB.NET, Энтони Грина. «Подобные ресурсы — это глубинные детали от экспертов, которые не так легко найти, читая документацию», пишет Эрик. Представляем вашему вниманию первую часть перевода статьи Энтони Грина «Исчерпывающий список различий между VB.NET и C#». Возможно, именно в этих различиях кроется секрет динамики рейтинга этих языков.

Стихотворение, навеянное после очередного разбора почты, неожиданно стало «техническими требованиями» по переносу процессов из почты в систему класса ServiceDesk.
И ведь главное, никому ничего не навязывали!

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

• долго
• неэффективно
• неудобно

(ИЛИ каламбур типизации, неопределенное поведение и выравнивание, о мой Бог!)

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

Что такое strict aliasing? Сначала мы опишем, что такое алиасинг (aliasing), а затем мы узнаем, к чему тут строгость (strict).

В C и C ++ алиасинг связан с тем, через какие типы выражений нам разрешен доступ к хранимым значениям. Как в C, так и в C ++ стандарт определяет, какие выражения для именования каких типов допустимы. Компилятору и оптимизатору разрешается предполагать, что мы строго следуем правилам алиасинга, отсюда и термин — правило строгого алиасинга (strict aliasing rule). Если мы пытаемся получить доступ к значению, используя недопустимый тип, оно классифицируется как неопределенное поведение (undefined behavior — UB). Когда у нас неопределенное поведение, все ставки сделаны, результаты нашей программы перестают быть достоверными.

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



Чтобы лучше понять, почему нас должно это волновать, мы обсудим проблемы, возникающие при нарушении правил строго алиасинга, каламбур типизаций (type punning), так как он часто используется в правилах строгого алиасинга, а также о том, как правильно создавать каламбур, наряду с некоторой возможной помощью C++20, чтобы упростить каламбур и уменьшить вероятность ошибок. Мы подведем итоги обсуждения, рассмотрев некоторые методы выявления нарушений правил строго алиасинга.

(ИЛИ каламбур типизации, неопределенное поведение и выравнивание, о мой Бог!)

Друзья, до запуска нового потока по курсу «Разработчик С++», остается совсем немного времени. Пришло время опубликовать перевод второй части материала, в которой рассказывается о том, что такое каламбур типизации.

Что такое каламбур типизации?

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



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

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

Я специализируюсь на анализе безопасности Windows приложений. Довольно часто изучение именно различных прав доступа занимает существенную долю исследования. Чтобы автоматизировать процесс поиска странных или неправильных прав доступа пришлось разбираться в SDDL (Security Descriptor Definition Language). Кому интересно научиться читать права в форме SDDL (например что-то такое O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)) и познакомиться с моей утилитой для работы с дескрипторами в таком формате, добро пожаловать под кат.

Когда мы с другом учились в школе и только мечтали стать разрабами, мы думали как сделаем вместе какую-нибудь штуковину — игру или супер-полезную программу.

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

Собравшись уже матерыми разрабами, мы решили, наконец, сделать свой проект — двумерную видеоигру. Так как друг был чистый фронт, а я фулстек, очевидной платформой для нас стал браузер. Раньше я разрабатывал фронт только на TypeScript, и мы подумали, никаких проблем, TS — всего-лишь надмножество JavaScript. Возьмем его и все пройдет гладко. Как бы не так. Когда мы начали обсуждать работу, столкнулись с невероятной бездной непонимания друг друга.

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

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

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

Screenagers — так с недавних пор в Америке называют подростков. Это слово образовано из двух английских слов: screen (экран) и teenager (тинейджер). Ведь нынешние подростки уже выросли с телефоном в руках.

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

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

За год, прошедший с релиза Kotlin 1.0, у языка произошли прорывы по многим фронтам: от поддержки в Gradle и Spring до выхода книги «Kotlin in Action». Число Kotlin-строк на GitHub возросло более чем вчетверо, превысив 10 миллионов. А теперь вышла версия 1.1, добавляющая компиляцию в JavaScript, и это выглядит громкой заявкой на новую долю рынка. Означает ли это всё, что вот теперь время Kotlin по-настоящему пришло, и нам всем пора активно использовать язык в продакшене?

Андрей Бреслав (JetBrains) и Антон Кекс (Codeborne) многое знают о Kotlin (и оба скоро выступят на JPoint с докладами о нём), но при этом смотрят на него с разных сторон: пока Антон разрабатывает на этом языке, Андрей работает над самим языком. Мы решили, что о настоящем и будущем Kotlin интересно поговорить с ними обоими сразу, получив полную картину. Начав с вопросов о бурном росте, затем успели обсудить ещё многое:

• Взаимодействие с разработчиками и процесс эволюции языка
• Компиляцию в JS, проект Kotlin Native и мультиплатформенность в общем
• Несовершенства
• Kotlin-паззлеры
• Ожидания и амбиции

Буквально пару дней назад в Денвере закончилась очередная, уже 5-я по счёту, крупнейшая конференция по Go – GopherCon. На ней команда Go сделала важное заявление – черновики предварительного дизайна новой обработки ошибок и дженериков в Go 2 опубликованы, и все приглашаются к обсуждению.

Я постараюсь подробно пересказать суть этих черновиков в трёх статьях.

Как многим, наверняка, известно, в прошлом году (также на GopherCon) команда Go объявила, что собирает отчёты (experience reports) и предложения для решения главных проблем Go – тех моментов, которые по опросам собирали больше всего критики. В течении года все предложения и репорты изучались и рассматривались, и помогли в создании черновиков дизайна, о которых и будет идти речь.

Итак, начнём с черновиков нового механизма обработки ошибок.