Коллега сфотографировал, недалеко от работы:

В продолжение прошлого поста.Разбирая архив, наткнулся на Image диска, который был благополучно запорот и выкинут. Так вот, бекап был в формате .ape (Monkey формат). Соответственно, стала задача - конвертировать Image в mp3. Гугл на пару с Яндексом выдал кучу рецептов, из которых я выбрал два самых простых:

1. Использовать CDEx (свободно распространяемый граббер CD, который умеет в том числе и грабить из образов. Лицензия GPL v.3)
2. CDi2MP3 (ссылка более не актуальна, 2016) - то же, что и CDEx. Только с непонятной лицензией - вроде свободный для использования.

Так как я раньше использовал CDEx, то начал с него. Конвертировал, все хорошо... но - в один большой mp3 файл :) ... для справки - конвертированный файл пишет в c:/programm files/cdex/my musik, под wine работает :)

Вторая программка оказалась умней - она разбивает все по отдельным файлам. (Ей, кстати, для полного счастья, нужен в системе lame-ncoder, то есть надо прописать путь до lame.exe в настройках). Конвертированные mp3 записываются в ту же папку, что и исходные - так что проблем вроде как быть не должно :) Под wine запускается, но не работает. Времени разбираться не было - поэтому запускал на рабочем ноутбуке (есть подозрение на lame, который или отсутствует или кривой - это по беглому взгяду на лог). А, еще - инсталляции не требует, распространяется в .zip архиве.

Из впечатлений (по Di2MP3 (ссылка более не актуальна, 2016) - новая таки штучка для меня) - ресурсов жрет, заразка ))) но, поскольку такого рода конвертации - операция штучная, а денег она (программка) за себя не просит - то можно и потерпеть...

Как обычно, возникла задача. Надо конвертировать некоторое количество музыки из MPC в MP3. Альбом джаза, который давно хотел послушать - и до которого наконец-то дошли руки. Недолгое гугление дало ссылку на замечательную софтину (под Windows) - Efficient WMA MP3 Converter.

Живет этот зверь по адресу http://www.wmamp3-converter.com/ и умеет конвертировать MP3, MP2, MP4, MPEG, WMA, WMV, OGG, APE, FLV, AVI, VOB, 3GP, FLAC, WAV, RealAudio, RealVideo, AAC, MOV, SWF, AC3, M4A, M4B,MPC, NUT в MP3, WMA, OGG Vorbis, MonkeysAudio (APE), WAV.

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

Помните известную фразу из фильма "Операция Ы"? "Бухти, бухти про космические корабли, бороздящие просторы Большого театра"...

Образно говоря, в жизни часто приходится заниматься именно этим: рассказывать о космических кораблях. Да, да - тех самых, которые бороздят просторы Большого театра. И не важно, что о космосе знаешь только то, что он есть; что "корабли" ассоциируются с модельками из магазина игрушек, в театре бывал - но ничего не понял, а слово Большой приводит на ум разнообразные ассоциации, которые к театру вообще-то отношения не имеют совсем никакого.

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

то будет странный пост... поток сознания:)

Итак, мы живем в эпоху глобального копипастинга. Копипастингом пишется код. Ооочень часто. Сознаюсь: у меня иногда хватает времени на то, чтобы сеть и кодировать. Так вот, в том, что я скромно именую "моя CMS" примерно 70% "моего" кода, и около 30 - копипастного. Я такой код обычно оформляю в отдельные файлики, складываю его в отдельный каталог, и всегда пишу - откуда стянуто... это не к тому, какой я хороший. А к тому, что когда попадается задачка уровня первого семестра "программирования" технического ВУЗа для непрограммистих специальностей, мне проще погуглив найти решение, чем думать.Времени точно займет меньше. Как показывают наблюдения, я не одинок: знакомые (программисты и другие ИТшные жители) говорят, что копипастится все: от конфигов до кода.

....А как же любимая всеми команда man? - грустно вздохнул серый ослик Иа-Иа.

да, да - и "мире linux" копипастинг тоже набирает обороты. "Не знаешь как? - скопируй"

Теперь о том, что ближе. О документации. В общем, ни для кого не секрет, что разного рода вендоры, внедренцы, ИТ-компании и прочие "братья по разуму" (работаю я в ИТ компании, у интегратора - если что, так что - точно братья) имеют наработанную библиотеку типовых документов и презентаций. Оно и неплохо, когда надо для продажи ... (хотя смотря для какой - бывают такие продажи, что под них готовится отдельный, независимый, не похожий ни на что пакет документации)... но вот когда копипастится проектная документация, или  в нее копипастятся отрывки из учебников - простите, не понимаю...

- Где? - спросите вы.

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

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

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

Кросспост из моего ИТшного блога на ITBlogs.ru

Я писал про замечательную книгу И.Ашманова "Жизнь в пузыре". Нахваливать еще раз не буду, а порекомендую еще один труд - на ту же тему, только немного в другом стиле и неизвестного автора/авторов (так как стоящие в заглавии "Доны Карлос, Климентис и Консалис" явно являются чьими-то псевдонимами. Называется произведение "Планктон-11", и описывает жизнь, похожую на "Жизнь в пузыре", только стилизованную - не то под сказку, не то под галлюцинацию. Читается тяжелее, требует вдумчивости, а описанные ситуации встречаются, наверное, в 70% российских компаний (и, наверное, в западных, наверное, тоже - просто не владею ситуацией).

В общем - однозначно рекомендую к вдмчивому прочтению.

UPD: ссылка

Давно я не писал ничего на ITBlogs. Исправляюсь....

Итак, из разряда "мысли вслух".

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

Доказательство: по ТЗ оценивается объем работ, который необходимо проделать, и, на основе этого объема - дается бюджетная оценка проекта (это допущение, так как все знают, что в 50% случаев бюджет возникает до ТЗ.. такой случай тут не рассматриваем). В бюджет обязательно закладываем риски. Маленький проект - это маленький бюджет. Маленький бюджет - небольшой бюджет на риски. Так как система сдается по ТЗ, то наличие обтекаемых и нечетких формулировок - это зона потенциального действия рискового бюджета. Который, как известно (см. выше) в небольших проектах невелик (а некоторых отсутствует совсем). То есть, наличие в ТЗ на маленький проект четких формулировок - явно снижает риски (не скажу, что всегда до уровня, который закладывается в бюджет, но снижает).

С другой стороны, "большой проект" просто и недвусмысленно напрашивается на обтекаемые формулировки: с одной стороны, на этапе ТЗ порой непонятно "до последнего винтика", что именно требуется сделать - и тогда в ТЗ возникают забавные формулировки, которые могут означать все, что угодно (да, это плохо; но - такова жизнь; но с этим приходится мириться и работать). Разворачивание этих формулировок в понятные для реализации может съесть весь бюджет рисков (а может и не съесть, или съесть - но не весь). Но, ввиду того, что в абсолютном выражении бюджет получается больше, наличие таких формулировок допустимо...

Если же вспомнить, что обычно (в правильных случаях - больших проектов) за ТЗ идет ТП, где описывается - КАК сделать все то, что описано в ТЗ, то вроде как возникает еще один повод расслабиться и вздохнуть с облегчением: уж в ТП-то будет описано все, до пресловутого "последнего винтика". Как бы ни так! В самом лучшем случае там будет описано процентов 70 того, КАК надо сделать описанное в ТЗ. 30% - на риски. Суровая правда жизни :)

Теперь к извечному - "кто виноват". Конечно, на старте расставить точки над "ё" - прямая обязанность РП. Но такое "расставление" обычно относится к организации проекта. За качество ТЗ тоже в общем случае отвечает он, в частном - аналитик, который ТЗ писал. Это если "в лоб". А если приглядеться более внимательно - то "дыры" в ТЗ (в виде обтекаемых и/или отсутствующих формулировок) вообще могут быть на совести заказчика (не важно - внешнего или внутреннего). В этом смысле задача РП - с одной стороны перенести ответственность за "головотяпство" на заказчика, а с другой - манипулируя этой ответственностью, результатом, сроком и качеством проекта, добиться минимально возможного числа такого рода "белых пятен". Кстати, даже то, что косвенным итогом такой работы будет понятный и конечный список "белых пятен" - уже вери гут.

Вот как-то так мыслится :)

Кросспост из моего ИТшного блога на ITBlogs.ru