Не секрет, что многие, до сих пор, прописывают тэги во всяких cp1251 и KOI-8R — после чего их не понимают ни телефоны, ни плееры (некоторые) и с проигрывателями под linux бывает много проблем.
Больше всего неприятно, то что при загрузке новой музыки, ты не можешь быть уверен в какой кодировке идут тэги и вот добавив в свой проигрыватель ты обнаруживаешь нечитаемые символы вместо названия трека, исполнителя и альбома. А ведь оно еще и на last.fm скроблится в таком виде.

Можно использовать EasyTag и прочие редакторы тэгов.
Но чаще всего, мне надо только поправить кодировку, а тэги прописаны верно.

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

Здравствуйте, дорогие айтишники!

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

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

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

Деактивируйте старый ПК вместо покупки новой лицензии

Лицензии на Windows стоят дорого. Цена официального ключа от Microsoft, от $100 до $200, может сравниться с ценой терабайтного твердотельного накопителя, 16 Гб RAM или материнской платы. А покупать дешёвые ключи с сомнительных веб-сайтов – это не очень хорошая идея. Поэтому платить за очередную лицензию, когда вы избавляетесь от старого компьютера в пользу нового – не очень интересная идея. Но хорошая новость в том, что можно деактивировать ПК, который вы больше не будете использовать, и перенести лицензию на новый.

Друзья, мы рады сообщить, что перевод всего гарвардского курса CS50 закончен.

Мы писали, что в курсе 24 серии, однако последние две оказались одной и той же лекцией (одна прочитана в Гарварде, а другая в Йеле), поэтому в списке переведённых лекций не 24, а 23.

Список лекций под катом.


Курс переведён и озвучен нашей студией по заказу JavaRush, и мы хотим сказать им огромное спасибо за поддержку!

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

Что там будет под капотом, ни одна живая душа уже не поймет. Команда «хреновина» интерпретируется в абзац с описанием, который интерпретируется в ключевые слова, который интерпретируется в набор векторных обозначений, который интерпретируется в какой-нибудь С, который скомпилируется в…

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

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

Просто я задумался — а не стали ли наши ЯПы уже чем-то таким? Чуть более умным эквивалентом фразы «компьютер, сделай хреновину». Кучей формализованных протоколов для электричества, про которое мы уже забыть забыли. Штукой, которая все сильнее рвет нашу связь с механической реальностью.

Я часто слышу фразу: «Фил, отступись, хватит думать обо всякой чепухе». Но блин, будь проклят тот день, когда на Хабре напишут «хватит думать».

Форумы по поиску работы пестрят сообщениями: “Я уже полгода\год ищу работу и рекрутеры мне отказывают, потому что непрофессиональные, думают, что раз никто не взял, то и нам не нужен”. Знакомо? Давайте разбираться.

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

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

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

Под катом вместе с Максимом Цепковым будем разбираться, какие уроки можно вынести из разных подходов, как проектировать документы проекта, что занести в wiki, для чего подойдет Google Docs, а что обязательно должно все время находиться перед глазами. Да и вообще, зачем нужна это вся документация. Заодно и тему управления знаниями затронем.

В продолжение статьи о тайм-менеджменте предлагаю вашему вниманию историю о своем опыте использования инструмента по работе с интеллект-картами. Последние десять лет я занимаюсь управлением проектами в ИТ и телекоме, и всё это время я использую MindJet MindManager. Сегодня я расскажу, как с его помощью можно организовать задачи проекта и всё то, что происходит в голове проектного менеджера. Рассчитываю, что вы прочтете эту статью, пока пьёте одну чашку кофе, а за несколько последующих — мы с вами её обсудим.

Из этого поста вы узнаете о принципах формирования интеллект-карт, основных фишках MindJet MindManager (далее — Mind) и особенностях его применения в проектной работе управленца.

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

Источник

О себе писать не буду (кто я и чем занимаюсь). Моя статья возможно ответит на эти вопросы.

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

Да, я — тестировщик. Хотя мои близкие меня постоянно спрашивают — «Ты точно тестировщик? Не похожа!» Очень смешно.

В общем статья сегодня вот о чем. Как правильно говорить — регрессионное или регрессивное тестирование? Как вы сами думаете? Лично я и мои «нормальные» коллеги заняты большую часть времени на работе, проводя регрессионное тестирование. Хм… А может они проводят всё-таки регрессивное тестирование? Пойду-ка спрошу у своих ребят. И вот я в поисках правды провела небольшой опрос среди 20 человек. Опрос легкий с одним вопросом — «привет! ты проводишь регрессивное или регрессионное тестирование?». Большая часть из них сказали «регрессионное», два человека сказали, что это для них одно и тоже, один сказал — «регрессивное». Опроса мне не хватило, и я пошла к знакомой (кандидат филологических наук), спросила про перевод слова «regression». Знакомая сказала, что переводится как регрессия, и скинула скрин вырезки этого перевода из multitran.ru. Оказывается как прилагательное это слово переводится и как «регрессионный», и как «регрессивный».

На Software Engineering Stack Exchange я увидел такой вопрос: «Что мешает широкому внедрению формальных методов?» Вопрос был закрыт как предвзятый, а большинство ответов представляли собой комментарии типа «Слишком дорого!!!» или «Сайт — это не самолёт!!!» В каком-то смысле это верно, но мало что объясняет. Я написал эту статью, чтобы дать более широкую историческую картину формальных методов (FM), почему они на самом деле не используются и что мы делаем для исправления ситуации.

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

I Вступление

Будку надо переносить! Сезона не бывает, чтоб пару-тройку не шандарахнуло.
То с туалетом путают, то с пляжной кабинкой…
(х/ф Особенности национальной рыбалки)

Конец года, подведение итогов, заполнение анкет и прочая предпраздничная мишура ИТ функционеров. Мне уже в который раз попадается на глаза итоговые опросники ИТ фирм, призванные выявить тренды в подходах к разработке продуктов. И каждый раз возникает ощущение какого-то подвоха, когда отвечаешь на вопросы типа: «Вы все еще пользуетесь методом Waterfall (водопадная модель), или Вы все-таки (как и все передовое человечество) практикуете Agile (гибкие методологии)». Когда же начинаешь выяснять у автора сего опроса, а что он понимает под Agile, его разъяснения как-то не сильно ложатся в канву манифеста (Agile Manifesto). О многих принципах он реально задумываются впервые и эти самые принципы прямо-таки ставят его в тупик. Но после небольшого замешательства, в ход идет тяжелая артиллерия с железобетонным обоснованием своей позиции: «Мы же не по Водопаду работаем, значит по Agile».

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

Давайте вместе, еще раз “ударим анализом” по теме Гибких методологий, попытаемся разложить основные артефакты и принципы по полочкам и отделить, тот сакральный смысл, который закладывали в это понятие изначально, от того, во что его превращают отдельные нерадивые популисты. Так же сравним подходы Agile с другими методиками для более точного понимания той грани, что их разделяет или наоборот – объединяет. Заодно попробуем выяснить, где использование принципов Agile наиболее целесообразно, а где не совсем уместно?

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

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

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

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

А я вот, за каким-то хреном, в один прекрасный момент стал использовать. Почему? И почему вы не используете?

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

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

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

Что же делать?

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3
Лекция 20: «Безопасность мобильных телефонов» Часть 1 / Часть 2 / Часть 3
Лекция 21: «Отслеживание данных» Часть 1 / Часть 2 / Часть 3

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

Вот, например:

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

Окончательный код составляет около 250 строк на C. Достаточно знать лишь основы C или C++, такие как двоичная арифметика. Для сборки и запуска подходит любая Unix-система (включая macOS). Несколько API Unix используются для настройки ввода и отображения консоли, но они не являются существенными для основного кода. (Реализация поддержки Windows приветствуется).

Примечание: эта VM — грамотная программа. То есть вы прямо сейчас уже читаете её исходный код! Каждый фрагмент кода будет показан и подробно объяснён, так что можете быть уверены: ничего не упущено. Окончательный код создан сплетением блоков кода. Репозиторий проекта тут.

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

Зачем мне это надо?

У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:

Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!

Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.

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

Мне очень грустно, когда я очередной раз слышу мнение, что тестировщик может достичь своего предела за 1,5 года, а дальше либо в автоматизацию, либо смена роли на менеджера, аналитика, разработчика и т. п. Когда твой каждый день — это просто повторение алгоритма: почитал аналитику, посмотрел прототипы, потестировал, запостил баги, перепроверил баги — то легко понять, почему ты устаёшь и разочаровываешься в профессии. Это же просто скучно!

Расшифровка выступления на конференции Web Camp Zagreb Мачея Цегловского, американского веб-разработчика, предпринимателя, докладчика и социального критика польского происхождения.

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

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

N¹⁴ + N¹⁴ ⇒ Mg²⁴ + α + 17,7 МэВ

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

Комментарий переводчика: Подробное интервью с легендарным лингвистом, вышедшее 6 лет назад, но ничуть не утратившее своей актуальности. Ноам Хомский —  «современный Эйнштейн», как его называют, делится своими соображениями об устройстве человеческого мышления и языка, искусственном интеллекте, состоянии современных наук. На днях ему исполнилось 90 лет, и это кажется достаточным поводом для публикации статьи. Интервью ведет молодой учёный-когнитивист Ярден Кац, он сам прекрасно разбирается в предмете, поэтому беседа очень содержательна, а вопросы столь же интересны, как и ответы.