Скорее всего система работала, а вот иксы зависли.
X это не только отображение, но и обработка устройств ввода. А вот acpi с иксы не связаны, потому при из смерти (глючный драйвер GMA 500 зависал, а не падал) система корректно выключалась по нажатию на кнопку питания.
Немного истории — C++ разработчик открывший для себя питон, как первый динамический язык программирования. Все так же люблю этот язык, иногда пишу на нем, но год назад перешел на Rails, а значит и Ruby.
Итак, причина выбора — Rails. Этого факта достаточно чтобы судить о схожести языков. Вокруг фреймворка сформировалось замечательное комьюнити придерживающиеся KISS, DRY принципов, развивающих TDD подход в BDD и SDD (RSpec & Cucumber). Они стремятся к совершенству, создают все новые и новые средства, но не забывают о новичках, предоставляя неплохие предложения по умолчанию. Очень много качественной литературы, в сети информации тоже хватает.
Ruby очень красивый и выразительный язык. Слова бессильны — нужно посмотреть.
Меня сложно назвать объективным, но это текущий выбор. Теперь изучаю Haskell, Lisp, Erlang… или вернусь к Python, дальше будет видно :)
Еще одна вещь которая может значительно ускорить обучение — знакомство с функциональным программированием. Для начала хватит поверхностного. Покажу на вашем примере набор методов:
* преобразование имени файла в итератор
* его фильтрация по функции is_comment
* преобразование линии в элемент (массив трех значений)
Для полного покрытия приложения достаточно описать эти методы. При этом в первом методе стоит не столько проверять метод open (он уже проверяется тестами реализации языка), сколько выводом данных в verbose режиме.
def test_should_print_data_points_count_and_filename_in_verbose_mode():
# не следует здесь проверять вывод данных
# только проверка интересующей строки по регулярному
RSpec позволяет создавать конкретизировать описание, создать несколько уровней. Не желая затрагивать файловую систему, мы используем стаб, подменяя результат на тестовую строку.
describe Calculation
describe «verbose mode»
subject { Calculation.new(:verbose => true) }
it «should print data points count and filename» do
File.stub!(:open).and_return([«some data»])
subject.process('filename').should match(«Read in 1 data points from monitor file filename»)
end
end
end
Одна из наиболее приятных вещей в TDD это определение интерфейса. В момент написания теста вы определяете как бы хотели увидеть интерфейс. Это очень важно. Не нужно думать о реализации — она сковывает действия.
Тесты это первые пользователи интерфейса. В отличии от кода проекта они чисты — к их коду не примешивается логика приложения.
Что же мы видим в тесте? Создание файла в тесте смотрится убого. Много лишних телодвижений, а главное они никак не относятся к сути решаемой задачи. Итак, тесты первые пользователи интерфейса, следующие — программисты. И они будут решать задачу точно так же!
Всегда стоит писать предполагая что человек поддерживающий код — маньяк знающий ваш адрес :)
Общие впечатления — глобальные переменные мозолят глаза. Их стоит вынести в метод и подключать по желанию. При использовании модуля другим человеком будет меньше неожиданностей. Далее по поводу тестов.
Это не TDD, а довольно многословный интеграционный тест, опирающийся на особенности интерпретатора (assertAlmostEqual как подсказали выше). Все что он может сказать — что-то не работает. Что же именно сломано показывают юнит тесты.
Также стоит посмотреть на иные системы тестирования, мне больше нравится nose somethingaboutorange.com/mrl/projects/nose/. А еще больше rspec rspec.info, руби комьюнити уделяют тестированию значительно больше внимание. И конечно обязательно стоит прочесть The RSpec Book.
TDD описывает функциональность. Например «комментарий начинается с решетки»
def test_comment_start_with_sharp():
assert is_comment("# comment")
assert not is_comment(«some data»)
Аналогично поступаем со всеми знаниями — формат строки (разделенный пробелами, три значения), выбрасывание исключения итд.
Это простые тесты. Тест «комментарии не добавляются в выборку» слегка сложнее
class TestMeasure:
def setUp(self):
self.measure = Measure()
Этот тест опирается на наше знание о комментарии. Это знание можно вынести в фабрики def create_comment_line(): return "# comment". Или использовать моки и стабы.
Плюшек не счесть:
* пользователь сам выбирает какие окна группировать
* доступно для всех приложений
* а значит тут же можно собирать окна скайпа
* группировка по типу — все браузеры в одной группе
* разнообразные методы конфигурирования — от плоских файлов до гуев
* множество решений от разнообразных производителей
* единый внешний вид и управление
Табы — костыль для устаревших оконных менеджеров:
* каждое приложение использует свою реализацию табов
* со своей логикой, управлением, шорткатами
* и эта логика отличается от переключения между окнами
Лучше (рабочие окружения, тайловые оконные менеджеры) давным давно сделано. И только пользователи самой распространенной оси о них не подозревают и продолжают хавать кактус :)
Pineview это серьезный шаг в направлении системы на кристалле. Практически вся логика на одном чипе!
> N450 saves on space and power consumption by incorporating a memory controller and graphics core, the GMA 3150. As a result, it does not require a separate northbridge and southbridge, but needs only an accompanying NM10 I/O controller.
А значит меньшее энергопотребление и меньшие размеры.
> According to Intel, the integrated graphics processing results in 20 percent lower overall power consumption, and a 60 percent smaller chipset footprint. In the case of the Mini 10 that means a claimed maximum of 9.5 hours of battery life, with an optional six-cell battery.
В отличии от Z 520 серии используется графический контроллер GMA 3150, базирующийся на GMA 3100. Линуксоиды поигравшиеся с Poulsbo должны вздохнуть с облегчением.
Links семейство использует схожий интерфейс (биндинги, меню, ). links и links2 отображают транслит, elinks — кириллицу. links2 имеет графический режим.
Ubuntu идет с w3m — поддерживает кириллицу, предоставляет более простой и удобный интерфейс (по крайней мера для виммера).
Способны ли пользователи заметить столь незначительно различающийся шрифт? И много ли дизайнеров могут использовать эту технологию во благо?
PS: В данный момент (под впечатлением The Humane Interface, а также оформления Pragmatics Programmers книг) работаю над предоставлением общего вида документов. Причины — большинство (оформителей, а как их еще назвать?) не способны содрать существующие решения. И даже в удачных случаях они удовлетворяют лишь стандартного клиента.
Да! Напомнило интернет на дискетах десять лет назад. Доступ раз в неделю со скоростью килобайт в секунду, папка «интернет» объемом меньше десятка мегабайт :D
Потому что рулит не код, а люди. Для изменения языка проекта необходимо на него пересадить своих разработчиков. А значит можно потерять людей, оставшиеся будут новичками в новом языке. Можно нанять профессионалов целевого языка, но эти люди не в курсе проблем проекта.
Использовать PHP или погубить проект это не выбор. Факт не свидетельствует о качестве языка и не должен использоваться при выборе языка для нового проекта.
Литературу подсказать?
«Каменяри» — произведение Ивана Франка.
X это не только отображение, но и обработка устройств ввода. А вот acpi с иксы не связаны, потому при из смерти (глючный драйвер GMA 500 зависал, а не падал) система корректно выключалась по нажатию на кнопку питания.
Итак, причина выбора — Rails. Этого факта достаточно чтобы судить о схожести языков. Вокруг фреймворка сформировалось замечательное комьюнити придерживающиеся KISS, DRY принципов, развивающих TDD подход в BDD и SDD (RSpec & Cucumber). Они стремятся к совершенству, создают все новые и новые средства, но не забывают о новичках, предоставляя неплохие предложения по умолчанию. Очень много качественной литературы, в сети информации тоже хватает.
Ruby очень красивый и выразительный язык. Слова бессильны — нужно посмотреть.
Меня сложно назвать объективным, но это текущий выбор. Теперь изучаю Haskell, Lisp, Erlang… или вернусь к Python, дальше будет видно :)
* преобразование имени файла в итератор
* его фильтрация по функции is_comment
* преобразование линии в элемент (массив трех значений)
Для полного покрытия приложения достаточно описать эти методы. При этом в первом методе стоит не столько проверять метод open (он уже проверяется тестами реализации языка), сколько выводом данных в verbose режиме.
def test_should_print_data_points_count_and_filename_in_verbose_mode():
# не следует здесь проверять вывод данных
# только проверка интересующей строки по регулярному
RSpec позволяет создавать конкретизировать описание, создать несколько уровней. Не желая затрагивать файловую систему, мы используем стаб, подменяя результат на тестовую строку.
describe Calculation
describe «verbose mode»
subject { Calculation.new(:verbose => true) }
it «should print data points count and filename» do
File.stub!(:open).and_return([«some data»])
subject.process('filename').should match(«Read in 1 data points from monitor file filename»)
end
end
end
В питоне обычно моделирую классами
class TestMeasure:
pass
class TestVerboseMeasure:
pass
Одна из наиболее приятных вещей в TDD это определение интерфейса. В момент написания теста вы определяете как бы хотели увидеть интерфейс. Это очень важно. Не нужно думать о реализации — она сковывает действия.
Тесты это первые пользователи интерфейса. В отличии от кода проекта они чисты — к их коду не примешивается логика приложения.
Что же мы видим в тесте? Создание файла в тесте смотрится убого. Много лишних телодвижений, а главное они никак не относятся к сути решаемой задачи. Итак, тесты первые пользователи интерфейса, следующие — программисты. И они будут решать задачу точно так же!
Всегда стоит писать предполагая что человек поддерживающий код — маньяк знающий ваш адрес :)
Необходимо избавится от временного файла
def integration_test():
data = ""«some
data»""
UC.readin_monitor(test_data)
В метод передается список, а значит можно передать файл в main
UC.readin_monitor(open(path))
Общие впечатления — глобальные переменные мозолят глаза. Их стоит вынести в метод и подключать по желанию. При использовании модуля другим человеком будет меньше неожиданностей. Далее по поводу тестов.
Это не TDD, а довольно многословный интеграционный тест, опирающийся на особенности интерпретатора (assertAlmostEqual как подсказали выше). Все что он может сказать — что-то не работает. Что же именно сломано показывают юнит тесты.
Также стоит посмотреть на иные системы тестирования, мне больше нравится nose somethingaboutorange.com/mrl/projects/nose/. А еще больше rspec rspec.info, руби комьюнити уделяют тестированию значительно больше внимание. И конечно обязательно стоит прочесть The RSpec Book.
TDD описывает функциональность. Например «комментарий начинается с решетки»
def test_comment_start_with_sharp():
assert is_comment("# comment")
assert not is_comment(«some data»)
Аналогично поступаем со всеми знаниями — формат строки (разделенный пробелами, три значения), выбрасывание исключения итд.
Это простые тесты. Тест «комментарии не добавляются в выборку» слегка сложнее
class TestMeasure:
def setUp(self):
self.measure = Measure()
def test_add_values(self):
self.measure.add(«some data»)
eq_(1, self.measure.count)
def test_skip_comments(self):
self.measure.add("# comment")
eq_(0, self.measure.count)
Этот тест опирается на наше знание о комментарии. Это знание можно вынести в фабрики def create_comment_line(): return "# comment". Или использовать моки и стабы.
Успехов
Hide Menubar addon помогает, но от альтернативных вариантов не откажусь
Плюшек не счесть:
* пользователь сам выбирает какие окна группировать
* доступно для всех приложений
* а значит тут же можно собирать окна скайпа
* группировка по типу — все браузеры в одной группе
* разнообразные методы конфигурирования — от плоских файлов до гуев
* множество решений от разнообразных производителей
* единый внешний вид и управление
Декомпозиция рулит
* каждое приложение использует свою реализацию табов
* со своей логикой, управлением, шорткатами
* и эта логика отличается от переключения между окнами
Лучше (рабочие окружения, тайловые оконные менеджеры) давным давно сделано. И только пользователи самой распространенной оси о них не подозревают и продолжают хавать кактус :)
Pineview это серьезный шаг в направлении системы на кристалле. Практически вся логика на одном чипе!
> N450 saves on space and power consumption by incorporating a memory controller and graphics core, the GMA 3150. As a result, it does not require a separate northbridge and southbridge, but needs only an accompanying NM10 I/O controller.
А значит меньшее энергопотребление и меньшие размеры.
> According to Intel, the integrated graphics processing results in 20 percent lower overall power consumption, and a 60 percent smaller chipset footprint. In the case of the Mini 10 that means a claimed maximum of 9.5 hours of battery life, with an optional six-cell battery.
В отличии от Z 520 серии используется графический контроллер GMA 3150, базирующийся на GMA 3100. Линуксоиды поигравшиеся с Poulsbo должны вздохнуть с облегчением.
Источник — гугл и www.linuxfordevices.com/c/a/News/Dell-Mini-10-2010-edition/
Links семейство использует схожий интерфейс (биндинги, меню, ). links и links2 отображают транслит, elinks — кириллицу. links2 имеет графический режим.
Ubuntu идет с w3m — поддерживает кириллицу, предоставляет более простой и удобный интерфейс (по крайней мера для виммера).
>> Project.last
**************************** 1. row ****************************
id: 82
user_id: 29
product_id: 11
created_at: Fri Nov 27 17:30:23 +0200 2009
updated_at: Mon Dec 14 15:02:24 +0200 2009
1 row in set
PS: В данный момент (под впечатлением The Humane Interface, а также оформления Pragmatics Programmers книг) работаю над предоставлением общего вида документов. Причины — большинство (оформителей, а как их еще назвать?) не способны содрать существующие решения. И даже в удачных случаях они удовлетворяют лишь стандартного клиента.
Программисты сталкиваются еще и с программными интерфейсами.
А потому рекомендую The Art of Unix Programming.
Использовать PHP или погубить проект это не выбор. Факт не свидетельствует о качестве языка и не должен использоваться при выборе языка для нового проекта.
Формат запроса может быть описан с использованием WADL.