Предложите, пожалуйста, хороший, желательно русскоязычный, туториал по этому редактору. И бумажную книжку — можно не совсем профильную, а и с другими темами, например. Спасибо.
Не в тему, но совсем немного: IPv6 не внедряете в почту для доменов тоже из-за безопасности (неизученности протокола в частности и реальной ситуации с ним в общем)? $ dig -t AAAA mx.yandex.ru +short
$
Справедливости ради приведу еще одну полезную ссылку по теме, которая мне помогла, без лишнего звена в виде хоста шлюза, включить принтер HP LJ 1005: samag.ru/archive/article/807 на клиенте был WinXP + данная настроенная медиация и виртуальный принтер, расшаренный в сеть Microsoft, который использовался клиентом с терминального сервера MS Windows Server 2008 R2.
Использовать слишком большие файлы
Использовать тяжелые фреймворки, когда это не нужно
Конкретный вопрос: можно ли подпилить для себя Dojo таким образом, чтобы не вляпаться ни в один из цитируемых моментов? Там будет работа с гридом, в основном.
Вот тут немного подробней про стиль расстановки скобок: тот, что Вам не нравится, называется K&R. Не думаю, что это принципиально; всё зависит от тех соглашений, которых Вы придерживаетесь.
На рынке нет, но инженерные образцы чипов и отладочных плат на их основе, полученные в ходе НИОКР, могут быть раздаваемы энтузиастам и разработчикам, в том числе свободным, для тестирования средств разработки, в т.ч. программных, и для подготовки к выходу как самихх чипов, так и устройств на их основе, на рынок. Как-то так.
Ну в общем, перебиваться случайными заработками, беря на дом случайную работу без ведома основной работы, которая в роли той компании — если на основной работе не принято брать работу на дом — тоже не получится. Либо если такую возможность дадут, то после этого начнут загружать не случайно, а явно и планомерно: и в отпуске, и на больничном, и в выходные, и в праздники, и по вечерам, и в отгулы. *сарказм*. Это я к тому, что дома надо не работать, а отдыхать. Тогда и появится нормальные условия, силы, режим дня для нормальной основной работы.
… то хочется поиграть под GNU/Linux на видеокарте от AMD/ATI, для которой проприетарные драйверы вносят в систему нестабильность, а свободные — не поддерживают 3D в полной мере для современных чипсетов. Нужно набраться терпения, и понять, что компьютерные игры — это тоже серьёзно, т.к. досуг, восстанавливающий силы. *сарказм*. Если по существу, то покупал в середине 200х по смешной цене русскую версию «Counter-Strike 1 Anthology», зарегистрировался на Steam, теперь вхожу туда, смотрю: у меня в кабинете написано что бесплатно, и нет возможости качнуть (т.е. некликабельно). А когда ищу этот же самый «Counter-Strike 1 Anthology» как в магазине, предлагают купить за 249р, и только под Windows. При желании конечно можно поставить, т.к. диск где-то валяется.
Ну если не брать работу на дом, то Office Home and Student должно быть вполне себе решение. Но там, к примеру, Outlook и Access нет. На дом серьёзную работу не возьмёшь. Либо с помощью freeware отсутствующие компоненты заменить. Но ведь это действительно только для студентов чтоб рефераты писать и несложные графики строить, простые тексты оформлять. Базы, даже настольные, для простого юзера не нужны, а если юзер непростой — уже деловая активность, приобретайте версию рангом выше. А для почты есть веб, а если календарь нужен и контакты — опять же занимаетесь делом, а не домашними делами, поэтому опять же смотрите на ранг выше. Вот такая логика.
Психологический посыл входа в ловушку понятен: не ошибается тот, кто ничего не делает. Т.е. надо выбрать такой угол вхождения в стартап — очень отличающийся от типового решения — при котором всё будет по-новому и неожиданному. Ведь проектировщик зачастую устаёт от отсутствия когнитивного сопротивления в процессе проектирования по шаблону, т.е. когда ситуация предельно ясна и прикладывать мозги особо не к чему, хочется почувствовать процесс проектирования хотя бы так: сделав маленькую революцию — ведь хочется делать работу, чувствуя себя умным, даже если работа — рутина на 99%. Но, вот с этого и начинаются проблемы. Ошибка такого посыла: в умозаключении вида «если ты не ошибаешься, то ты ничего не сделал; поэтому надо создать такую ситуацию, которая бы обеспечивала появление ошибки в проекте».
Кто умеет правильно бэкапить своё виртуальное железо, тому никакие пожизненные лицензии не страшны. Но, конечно, такой подход не для всех, понимаю. Но всё же.
Если проект (не только предметная область, но и архитектура самого проекта, плюс все уровни от концепции до границы, где начинается реализация) хорошо изучен, задокументирован, согласован, стабилен — то есть определённая вероятность того, что выбор языка программирования для реализации проекта не будет существенным; разумеется, для этого должно быть явное требование максимальной абстрагированности реализации от выбора языка программирования и, если надо, — среды (вплоть до операционной системы и программной платформы). Даже если проект не влезает в такие требования, вполне можно поднапрячься и проанализировать, хотя бы на бумаге, насколько реален рефакторинг проекта в эту сторону. Если ответ на вопрос «что надо кодить?» — пройденный этап, как, например, таблица умножения для старшеклассника, только начинающего изучать [новый] алгоритмический язык, для которого поставили задачку вывести эту таблицу на экран — а он знает её наизусть, причём уже не первый год — то почему бы и нет? ведь для него реализуемость задачи, так сказать, математически доказана, и он знает, что на компьютере такое можно делать, и любой вполне развитый язык программирования справится с этим. Опять же, никто не отменял практику написания прототипов, [грубо] оценивающих совместимость требований проекта со средой программирования. Однако, если надо перенести сложный проект, и трудоёмкость этого переноса оценивается как большая, то да — вопрос нетривиален; но надо учесть, что рано или поздно реализация любого сложного проекта рискует стать унаследованным ПО, поэтому у проектов с претензией на долгожительство должны быть ресурсы для регулярных перевыпусков своих реализаций в новых окружениях. Также, можно подумать о кроссплатформенности или хотя бы о её аналогии и методах, применяемых при её использовании: в том смысле, что при появлении новой (необязательно принципиально новой) платформы проект должен попытаться сделать свою реализацию под неё. При этом в природе существуют такие пугающие воображение параноидальные варианты реализации, как прикладное ядро, написанное на отдельно стоящем языке программирования прикладного уровня, не зависящее от основного языка реализации, «живущее своей жизнью»; генератор исходного кода для нужной среды программирования; и т. п. Хотя, конечно, пока проект юн, надо начинать с простого и очевидного.
Выдираем звук из видео в формате MP4 и сжимаем его в MP3:
$ cat mp4tomp3.sh
#!/bin/sh
for file in "$@" ; do
name=`echo "$file" | sed -e "s/.mp4$//g"`
ffmpeg -i "$file" -ac 2 -f wav - | lame --preset standard - "$name.mp3"
done
Cкрипту года полтора; надо было быстро вынуть звук из видеозаписи мероприятия, сделанной на портативную видеокамеру, раздать его в виде файликов через болванки CD или флешки, в формате, который все могут прослушать, и вот: этот алгоритм спас. Похоже, был единичный случай его применения, но он был весьма полезный и своевременный. Взял вот отсюда, пост от January 26th, 2009, 11:26 PM.
Слово EEPROM всегда тождественно слову FIRMWARE, или я что-то не понимаю?
Т.е. при включении FIRMWARE загружается из EEPROM, а при загрузке драйвера может быть загружен другой FIRMWARE, более новый и совершенный, чем тот, который загружен ранее из EEPROM, с исправлением ошибок? Но, вроде EEPROM — это не только FIRMWARE, но и всякие константы управляющие. Читал как-то в сети одну страшную историю, что запись неправильного значения байта по определённому адресу EEPROM может сразу убить сетевую карту наповал, что не лечится даже холодной перезагрузкой.
Казалось бы, всё просто:
Проект готов — заказчик вправе пользоваться, проектроовщик вправе получить гонорар.
Далее, если проект готов полностью, и заказчик вполне убедился в этом то зачем вообще нужна помощь со стороны проектировщика?
Здесь упускается из виду, что как только изменилось какое-нибудь из важных, пусть и неявных, конкретных технических требований — это, извините меня, уже другой проект; и хотя редко кто об этом говорит, почти все это понимают.
Либо, есть требование вечной жизни проекта — явное или нет: чтобы последняя часть жизненного цикла, т.е. стадия, соответствующая пункту «Эксплуатация и сопровождение» водопадной модели, была бесконечной и/или бесплатной.
С этой точки зрения, первородный грех всякого программного проекта — его отклонение от водопадной модели, предполагающей последовательный, целенаправленный рост и в конечном счёте — практическое и доказанное, гарантированное достижение требований.
Если требования — это река, в которую, одну и ту же, нельзя войти даже один раз, то риторический вопрос, который ставит данный топик, безусловно, имеет смысл.
В небольшой команде потеря времени от смены или ухода разработчика будет очевидна. В огромной компании, где программистов десятки и сотни, может возникнуть иллюзия того, что сотрудника можно незаметно заменить.
Как тут не вспомнить закон Брукса — гласящий, что добавление в программный проект новых людей еще больше оттягивает срок его реализации?
uCoz заявляет себя как SaaS, и, в общем-то, понятно желание всего прогрессивного человечества им не пользоваться, а делать всё самостоятельно, как и предлагает, например, Ричард Столман, который резко против этой нынче модной методологии построения ИС. Но, кому важна прикладная часть задачи, и нет ни времени, ни желания копаться в тегах HTML и других технических вещах, ни приобретать точные, практические знания о внутренностях сайта, а просто найти готовый шаблон и поместить в него свой контент, чтоб сразу было на что смотреть — наверно так и сделают; причём в последствии у них также будет не менее веский повод говорить о своей самостоятельности: не привлекали никого со стороны, uCoz же использовали как нечто базовое, как, если можно выразиться, подставку под контент — а ведь только контент придаёт окончательный смысл всей этой конструкции. Поэтому можно сказать, что в этом смысле narod.ru после переезда на новый хостинг стал определённо ближе к народу.
Благодарю за ссылку! Так понял, данная фирма всерьёз занимается унаследованным софтом и старым железом: у неё и для печати через рабочие станции есть что-то похожее по замыслу, под названием ScrewDrivers for Workstations. И для сканеров кое-что.
После сборки командой make, запустил ./src/vim
Не хочет выполнять команду
Либо надо поставить в систему, сделав make install, либо вспоминать старую добрую слаку, хотя б на виртуальной машине поднять )
$ dig -t AAAA mx.yandex.ru +short $Конкретный вопрос: можно ли подпилить для себя Dojo таким образом, чтобы не вляпаться ни в один из цитируемых моментов? Там будет работа с гридом, в основном.
$ cat mp4tomp3.sh
Cкрипту года полтора; надо было быстро вынуть звук из видеозаписи мероприятия, сделанной на портативную видеокамеру, раздать его в виде файликов через болванки CD или флешки, в формате, который все могут прослушать, и вот: этот алгоритм спас. Похоже, был единичный случай его применения, но он был весьма полезный и своевременный. Взял вот отсюда, пост от January 26th, 2009, 11:26 PM.
Т.е. при включении FIRMWARE загружается из EEPROM, а при загрузке драйвера может быть загружен другой FIRMWARE, более новый и совершенный, чем тот, который загружен ранее из EEPROM, с исправлением ошибок? Но, вроде EEPROM — это не только FIRMWARE, но и всякие константы управляющие. Читал как-то в сети одну страшную историю, что запись неправильного значения байта по определённому адресу EEPROM может сразу убить сетевую карту наповал, что не лечится даже холодной перезагрузкой.
Проект готов — заказчик вправе пользоваться, проектроовщик вправе получить гонорар.
Далее, если проект готов полностью, и заказчик вполне убедился в этом то зачем вообще нужна помощь со стороны проектировщика?
Здесь упускается из виду, что как только изменилось какое-нибудь из важных, пусть и неявных, конкретных технических требований — это, извините меня, уже другой проект; и хотя редко кто об этом говорит, почти все это понимают.
Либо, есть требование вечной жизни проекта — явное или нет: чтобы последняя часть жизненного цикла, т.е. стадия, соответствующая пункту «Эксплуатация и сопровождение» водопадной модели, была бесконечной и/или бесплатной.
С этой точки зрения, первородный грех всякого программного проекта — его отклонение от водопадной модели, предполагающей последовательный, целенаправленный рост и в конечном счёте — практическое и доказанное, гарантированное достижение требований.
Если требования — это река, в которую, одну и ту же, нельзя войти даже один раз, то риторический вопрос, который ставит данный топик, безусловно, имеет смысл.
Как тут не вспомнить закон Брукса — гласящий, что добавление в программный проект новых людей еще больше оттягивает срок его реализации?