Обновил прошивку в своем PocketBook (15.2).
Пропал баг с обновлением экрана. Вздохнул с облегчением.
Собственно, мне даже стало казаться, что я умудрился этот гаджет где-то уронить. Отсюда на экране при листании появлялись размытые места. Например половина экрана четкая, а на второй часть текста и интерфейса отрисованы так, будто на бумаге печатал принтер, у которого заканчивается тоннер. Иногда это явление портило весь экран. Перелистывание, на другую страницу и назад, меняло картину, но "портилась" следующая картинка, иногда через несколько страниц.
Видимо разбираться нужно было бы серьезно, поэтому откладывал, времени не было.
Ну да и хорошо, что хорошо кончается.
Последнее время заметил один баг у AdobeViewer. Возникает во время чтения pdf-файлов, при указании масштаба "по ширине", или указать его вручную.
Доходим до конца страницы, нажимаем "вниз", перескакиваем на следующую.
Возвращаемся назад (жмем "вверх") -- часть текста предыдущей страницы (в ее низу), не видна -- белый лист. Верхняя часть страницы, если поднятся выше, видна. Будто бы обрезали.
Кроме того, у AdobeViewer появился новый баг. Просмотр pdf-документа при масштабе "Компоновка" возможен только вперед. Кнопка "назад" перелистывает документ не на предыдущую, а на следующую страницу.
Чуть больше радует pdfviewer. Хотя в режиме компоновка он по прежнему не показывает некоторые pdf-файлы, например журнал fprog, зато упомянутые баги AdoveViewer его не коснулись.
На сегодня имеем два pdf-просмотрщика: один работает хреново, второй -- еще хреновее. Злорадно отмечу, что хреновее работает проприетарное решение. Но вцелом пользоваться устройством пока можно. Был бы доступен только один просмотрщик, было бы значительно хуже.
Надо будет send-pr сделать, если не забуду.
понедельник, 14 июня 2010 г.
пятница, 11 июня 2010 г.
Синтаксический сахар
Java -- трехлитровая банка с водой.
Python -- двухлитровая банка со сладким компотом.
Haskell -- пачка сахара-рафинада. Если кому сильно сладко, или беззубый, а кусочки дерут горло, запивают чем могут.
Scala -- банка Python, в которую впихнули и утрамбовали много пачек сахара-рафинада.
Lisp -- дольки сладких сухофруктов, которыми выкладывают магические узоры на тарелке. С виду невзрачные, но если уж кто подсел, то надолго.
Clojure -- компот из сухофруктов.
Эрланг -- банка с кучей мелких драже.
C# и F# -- леденцы, которые разрешают только сосать.
Теперь понимаю природу вечных стычек Лисперов с Хаскелитами. Редко кто может заедать сухофрукты рафинадом. Знаю одного, но он запивает рафинад компотом из сухофруктов.
Python -- двухлитровая банка со сладким компотом.
Haskell -- пачка сахара-рафинада. Если кому сильно сладко, или беззубый, а кусочки дерут горло, запивают чем могут.
Scala -- банка Python, в которую впихнули и утрамбовали много пачек сахара-рафинада.
Lisp -- дольки сладких сухофруктов, которыми выкладывают магические узоры на тарелке. С виду невзрачные, но если уж кто подсел, то надолго.
Clojure -- компот из сухофруктов.
Эрланг -- банка с кучей мелких драже.
C# и F# -- леденцы, которые разрешают только сосать.
Теперь понимаю природу вечных стычек Лисперов с Хаскелитами. Редко кто может заедать сухофрукты рафинадом. Знаю одного, но он запивает рафинад компотом из сухофруктов.
Не забываем о ресурсах
Готовый тестовый пример на Scala, c тредами. Создается 2000 тредов, которые делают что-то необременительное. Запускаю -- "java.lang.OutOfMemoryError: unable to create new native thread". Чудненько. Пляски вокруг параметров виртуальной машины не помогают, или наборот -- загоняют jvm в "корку".
Читаю документацию, ссылки, маны, пробую, комбинирую... температура (у меня и у проца) выросла еще на четыре градусов. Замечаю нюанс: ulimit во freebsd не показывает ограничения на кол-во тредов. В мане (bash) ключ "-T" есть, а в самой утилите -- нет. В линуксе, кстати, man правильнее, ключ там не указан.
И тут наступает прозрение.
Меняю на max_threads_per_proc до 2000, и сразу все как по маслу.
Никогда програмисты сами не научатся создавать сообщения об ошибках, точно отражающие ситуацию, если их жестоко не пинать. По себе знаю. :(
Читаю документацию, ссылки, маны, пробую, комбинирую... температура (у меня и у проца) выросла еще на четыре градусов. Замечаю нюанс: ulimit во freebsd не показывает ограничения на кол-во тредов. В мане (bash) ключ "-T" есть, а в самой утилите -- нет. В линуксе, кстати, man правильнее, ключ там не указан.
И тут наступает прозрение.
sysctl kern.threads.max_threads_per_proc: 1500Уменьшаю кол-во тредов до тысячи, работает. Поднимаю до полторы тысячи, перестает.
Меняю на max_threads_per_proc до 2000, и сразу все как по маслу.
Никогда програмисты сами не научатся создавать сообщения об ошибках, точно отражающие ситуацию, если их жестоко не пинать. По себе знаю. :(
четверг, 10 июня 2010 г.
Оформление исходных текстов
Заболел! Летом, блин!
И вот решил побрюздать, по мелочи, на избитые темы.
О стилях кодирования говорилось много. Существуют стронники жесткого следования стилю, сторонники допустимых послаблений. Есть те, кто плюют на всех -- "пишу как хочу".
Благодаря моему непосредственному начальнику я давно стал сторонником строгого следования в собственных исходных текстах (своих и рабочих). Места, которые вынуждено соприкасаются с внешним кодом, могут использовать другой name-convention для сглаживания перехода. В зависимости от инструмента (языка программирования), становится очевидно, что может быть применено и может ли вообще. Есть места, которые могут иметь отклонения и варианты. Все это оговаривается на начальных стадиях, каждый участник работы подтверждает согласие пользоваться стилем, и ему следуют.
Просто стиль должен быть естественным, логичным и обдуманным. Даже в мелочах.
Но бывает, что читаю о людях, которые утверждают, что ему удобнее (он привык), например, не ставить пробел после управляющего слова, а ставить его после скобок. И скулят, что его свободу ущемляют, когда за подобные места делается замечание.
Есть языки, в которых присутствуют некоторые особенности: как синтаксиса языка, так и стиля, устоявшегося в его сообществе. Да, подобное логично учитывать (в той или иной мере), при составлении своего стиля оформления. Никто не говорит, что исходные тексты языков программирования всегда могут быть похожи на естественные языки. Некоторые моменты вводить невозможно физически, или просто не целесообразно.
Но вой о том, что свободу ущемляют, это просто превыше моих сил. Свой псевдокомфорт ставится выше, чем продуктивность всей команды. Если вы считаете, что круче своей команды вместе взятой, так работайте один. Если нет, и ваши дурные привычки для вас важнее, то вы хуже избалованного ребенка, ковыряющего пальцем в носу на людях, и хнычущего, когда его отрывают (было ведь так хорошо и удобно). Более слабые и сильные коллеги должны читать вашу "резьбу по коду", в самих исходниках, в "патчах"/"диффах", и видеть ваше неуважение к ним в элементарных вещах.
Я не говорю, что никто не допускает ошибок, не забывается -- это все естественно. Но во-первых, следить за оформлением совсем не трудно, и это хорошая привычка. Во-вторых, уже давно есть автоматические оформители исходников, которые можно запускать перед "коммитами" (хоть автоматически). В конце-концов, если пользуетесь IDE, то все современные продукты можно настроить на использования нужного стиля, оно автоматически за вас все сделает.
Сознательное нежелание использовать общий стиль, попытка выделиться в такой мелочи и сделать исходники неоднородными -- неуважение к коллегам, к их времени. Однородные исходники читаются и обозреваются намного лучше. Чтение исходников -- значительная часть рабочего времени, а это время ваше, и ваших коллег.
Привыкайте, блять, уважать чужой труд!
И вот решил побрюздать, по мелочи, на избитые темы.
О стилях кодирования говорилось много. Существуют стронники жесткого следования стилю, сторонники допустимых послаблений. Есть те, кто плюют на всех -- "пишу как хочу".
Благодаря моему непосредственному начальнику я давно стал сторонником строгого следования в собственных исходных текстах (своих и рабочих). Места, которые вынуждено соприкасаются с внешним кодом, могут использовать другой name-convention для сглаживания перехода. В зависимости от инструмента (языка программирования), становится очевидно, что может быть применено и может ли вообще. Есть места, которые могут иметь отклонения и варианты. Все это оговаривается на начальных стадиях, каждый участник работы подтверждает согласие пользоваться стилем, и ему следуют.
Просто стиль должен быть естественным, логичным и обдуманным. Даже в мелочах.
Но бывает, что читаю о людях, которые утверждают, что ему удобнее (он привык), например, не ставить пробел после управляющего слова, а ставить его после скобок. И скулят, что его свободу ущемляют, когда за подобные места делается замечание.
if( expr)Люди, не порите чушь -- "она визжит и брыкается". Вы, когда пишете по-русски, ставите пробел перед открывающейся скобкой, и наоборот, не ставите пробел за ней. Делаете это автоматически и не причитаете о каких-то ущемлениях. Более того, грамотно писать вы уже привыкли (если вообще умеете), вас этому долго учили. Так чего же вы теперь выебываетесь?! Т.е. десять лет вы привыкали писать с соблюдением одного стиля, а потом за пару лет привыкли писать нарушая правила? Вас что, пиздили, чтобы добиться нужного эффекта? Более того, в своих ЖЖ-шечках вам удобно писать по-русски правильно, а в исходниках меняется мировоззрение?
if ( expr)
Есть языки, в которых присутствуют некоторые особенности: как синтаксиса языка, так и стиля, устоявшегося в его сообществе. Да, подобное логично учитывать (в той или иной мере), при составлении своего стиля оформления. Никто не говорит, что исходные тексты языков программирования всегда могут быть похожи на естественные языки. Некоторые моменты вводить невозможно физически, или просто не целесообразно.
Но вой о том, что свободу ущемляют, это просто превыше моих сил. Свой псевдокомфорт ставится выше, чем продуктивность всей команды. Если вы считаете, что круче своей команды вместе взятой, так работайте один. Если нет, и ваши дурные привычки для вас важнее, то вы хуже избалованного ребенка, ковыряющего пальцем в носу на людях, и хнычущего, когда его отрывают (было ведь так хорошо и удобно). Более слабые и сильные коллеги должны читать вашу "резьбу по коду", в самих исходниках, в "патчах"/"диффах", и видеть ваше неуважение к ним в элементарных вещах.
Я не говорю, что никто не допускает ошибок, не забывается -- это все естественно. Но во-первых, следить за оформлением совсем не трудно, и это хорошая привычка. Во-вторых, уже давно есть автоматические оформители исходников, которые можно запускать перед "коммитами" (хоть автоматически). В конце-концов, если пользуетесь IDE, то все современные продукты можно настроить на использования нужного стиля, оно автоматически за вас все сделает.
Сознательное нежелание использовать общий стиль, попытка выделиться в такой мелочи и сделать исходники неоднородными -- неуважение к коллегам, к их времени. Однородные исходники читаются и обозреваются намного лучше. Чтение исходников -- значительная часть рабочего времени, а это время ваше, и ваших коллег.
Привыкайте, блять, уважать чужой труд!
воскресенье, 23 мая 2010 г.
Редко интересуюсь закадровыми голосами
Но в этот раз решил полюбопытствоать, кто же исполнитель песни в мультике из предыдущего поста. Это Ольга Рождественская, ребенком спевшая немало песен к популярным советским фильмам. Что я могу сказать, голос мне ее очень нравится: мощный, чистый и красивый. В "дельфинах" под песню он вообще очень удачно подошел.
Собственно, это и не удивительно, если послушать, как пела ее мать -- Жанна Рождественская, спевшая еще большее кол-во песен к куче фильмов. Собственно, голос Жанны оказался даже там, где всегда подразумевались другие исполнители. Но мне простительно -- слуха почти нет. Однако и его остатков вполне хватает для наслаждения красивыми песнями.
Собственно, это и не удивительно, если послушать, как пела ее мать -- Жанна Рождественская, спевшая еще большее кол-во песен к куче фильмов. Собственно, голос Жанны оказался даже там, где всегда подразумевались другие исполнители. Но мне простительно -- слуха почти нет. Однако и его остатков вполне хватает для наслаждения красивыми песнями.
Хороший мульт: "Девочка и дельфин"
Показывал полуторогодовалой дочке советский мультфиль,- "Девочка и дельфин". Детке, вцелом, нравится.
Мультик короткометражный, наверное низкобюджетный, однако песня и мелодия впечатляет (скорее-всего, написана для мульта). Вот что-то не припомню иностранных мультов из той же "весовой категории", с подобными песнями и музыкой. Или что-нибудь готовенькое-популярное, или какая-нить простенькая напевалочка. Но хотелось бы глянуть.
Мультик короткометражный, наверное низкобюджетный, однако песня и мелодия впечатляет (скорее-всего, написана для мульта). Вот что-то не припомню иностранных мультов из той же "весовой категории", с подобными песнями и музыкой. Или что-нибудь готовенькое-популярное, или какая-нить простенькая напевалочка. Но хотелось бы глянуть.
среда, 5 мая 2010 г.
Подписаться на:
Сообщения (Atom)