Недавно я прочитала пост "Энциклопедия заморочек творческого человека", и подумала, что нужно написать, что получается делать, когда делать ничего не хочется. С рукоделием все просто: если я не хочу ничего делать, то можно ничего и не делать. Рукоделие для меня - это бонус, это отдых. Но программирование - работа. Самая большая трудность в программировании сейчас - работа на дому. В офисе среди коллег приходится держать себя в руках, а вот дома ситуация расслабляющая. И когда работать не хочется, когда в голову не идут никакие мысли, я перво- наперво вытаскиваю себя к рабочему компьютеру. Затем заставляю себя его включить и дождаться, пока он загрузится. А затем начинаю делать работу, ту, которя достаточно тупая, чтобы думать по-минимуму. Например, начинаю простой рефакторинг, после которого не нужно все заново тестировать, но который позволяет сделать код более читаемым. Или чищу папку с билдами. Или пишу комментарии. Или пересматриваю код, нахожу нестыковки, над которыми нужно будет подумать. Те вещи, которые требуют хороших раздумий я не делаю. Если нахожу что-то, то записываю, что обнаружила, и иду дальше. И так до того момента, как не найду что-то, что меня зацепит и с чем я захочу повозиться побольше. Если такое нашлось, то значит я опять в рабочем режиме и можно жить дальше.
воскресенье, 14 сентября 2014 г.
пятница, 5 сентября 2014 г.
Qt, пока все еще qt.
Бьюсь с qt creator за правильное расположение виджетов. Бой неравный. В первом раунде, при расположении horizontal layout, я выйграла. Все отображается как надо. Но победа оказалась добыта только после такого финта ушами, что ужас просто. Чтобы компоновщик заработал, его обязательно нужно включить через меню вызова компоновщика, при выделении нескольких объектов для компоновки. При том, что в дизайнере есть объект компоновщика на панели для перетаскивания. Но если просто его перетащить, то работать почему-то не будет. Ужас. Настроить компонтвщик для своих самодельных виджетов у меня пока так и не вышло. Они выравниваются вручную. Хорошо что я догадалась их поместить на одну панель. Панель из стандартных виджетов, поэтому она компоновщику подвластна. Еще одна непонятная вещь -как вручную править horizontal header элемента table view. Примеры из интернета не хотят компилироваться. Он редактируется только через дизайнер. Так что, вопросов к qt пока намного больше, чем ответов.
вторник, 5 августа 2014 г.
Имитационное моделирование
вторник, 10 июня 2014 г.
Как изучать чужой код
Во-первых, для того, чтобы изучить программу нужны исходники. О том, как исследовать программу без исходников ищите другие материалы в статьях по хакерство.
пятница, 16 мая 2014 г.
Что такое HLA?
Что такое HLA
HLA (High Level Architecture, архитектура высокого уровня) - это архитектура для моделирования и имитирования. Используя HLA компьютерные модели могут взаимодействовать (т.е. обмениваться данными и синхронизировать действия) с другими компьютерами, не смотря на различие платформ. Взаимодействия между моделями управляеся RTI (Run-Time Infrastructure Инфрастструктура среды исполнения?).HLA - это стандарт возможности взаимодействия для распределенных моделей, применяемый для поддержки ананлиза, разработки и управления, тренировки в некоторых областях, как:
- средства обороны;
- управление воздушным транспортом;
- здравоохранение.
Она разработана под стандартом IEEE1516.
IEEE 1516-2010 - Стандарт архитектуры высокого уровня для моделирования и имитации - структура и правила.
IEEE 1516.1-2010 -Стандарт архитектуры высокого уровня для моделирования и имитации - спецификации федерального интерфейса (сервера).
IEEE 1516.2-2010 - Стандарт архитектуры высокого уровня для моделирования и имитации - спецификация шаблона объектной модели.
IEEE 1516.3 - 2003 Рекомендуемая практика разработки HLA федерации и процесс использования.
IEEE 1516.4-2007- Рекомендуемая практика для проверки, валидации и аккредитации федерации как надстройка над разработкой HLA федераций и процессом использования.
Технический обзор
HLA состоит из следующих компонентов:- Cпецификация интерфейса(Interface specification): определяет, как HLA совместимые модел взаимодействуют с RTI, предоставляющим библиотеку и api (прикладной программный интерфейс) совместимый с интерфейсной спецификацией.
- Шаблон объектной модели(Object Model Template): определяет какая информация взаимодействует между моделями и как она документируется.
- Правила(Rules). Модель жестко подчиняется, для того, чтобы соответствовать стандарту.
- Федерат(Federate). Сущность, единица модели, совместмая с HLA.
- Федерация(Federation) - множество моделируемых сущностей, соединяющихся с помощью RTI, используя шаблон объектной модели(OMT).
- Объект(Object) - набор связанных посылок данных между моделями (? тактами моделирования).
- Атрибут (Attribute) - поле данных объекта.
- Взаимодействие(Interaction) - действие, посланное между модельными сущностями.
- Параметр(Parameter) - поле данных или взаимодействие.
Спецификация интерфейса.
Спецификация интерфейса объектно-ориентированно в соответствии с техническими условиями С++ или Java. Она разделена на группы:- Управление федерациями.
- Управление объявлениями.
- Управление объектами.
- Управление имуществом(ownership).
- Управление временем.
- Управление распределением данных.
- Сервисы поддержки.
Шаблон объектной модели.
Шаблон объектной модели представляет собой общую структуру для коммуникации между HLA моделями. Он зависит от следующих документов:- объектная модель федерации(FOM);
- объектная модель одного федерата(SOM).
Правила.
Правила описывают обязанности федерации и присоединенных федератов.- Федерации должны иметь HLA FOM, документированную в соответствии с HLA шаблоном объектной модели.
- В федерации все представления об объектах в FOM должны быть в федератах, а не в инфраструктуре (RTI).
- В течение работы федерации все обмены данными между федератами должны проходить с помощью RTI.
- В течение работы федерации, федераты должны взаимодействовать с RTI в соответствии со спецификацией интерфейсов HLA/
- В течение работы федерации атрибуты текущего состояния объекта должны принадлежать только одному федерату в любой момент времени ( не поняла точно этот пункт, поэтому привожу оригинал:During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.)
- Федераты должны иметь HLA SOM, документированную в соответствии с HLA OMT.
- Федераты должны быть способны обновлять и/или отражать любые атрибуты объектов в их SOM и посылать и/или получать SOM взаимодействие извне, как установлено в их SOM.
- Федераты должны быть способны передавать и/или принимать имущество (ownership) атрибута динамически в течение работы федерации, как установлено в их SOM.
- Федераты должны быть способны изменить условия, под которыми они осуществляют обновления атрибутов объектов, как установлено в их SOM.
- Федераты должны быть способны управлять локальным временем способом, который позволит им координировать обмен данными между федератами.
OpenRTI
OpenRTI это реализация RTI c открытым исходным кодом. Эта реализация представляет следующие три версии RTI:RTI13 - HLA версия 1.3
RTI1516 - первый HLA стандарт версии 1516
RTI1516e - HLA стандарт 1516-2010
Итак, перевод закончен.
Из ближайших планов на работу: мне необходимо изучить интерфейс RTI1516, т.к. он используется. Ура. Это только одна папка из трех. Хоть чуть понятнее стало.
четверг, 8 мая 2014 г.
Качество ПО, часть 2.
Эффективная программа контроля качества включает комбинацию методик проверки, применяемые на всех этапах разработки. Макконнелл предлагает следующую комбинацию методик, для достижения высокого качества ПО:
- формальные инспекции требований, аспектов архтектуры, всех проектов критических частей системы;
- моделирование или прототипирование;
- чтение или инспекции кода;
- тестирование выполнения программ.
Лучшим способом повысить производительность труда программистов является минимизация времени, затрачиваемого на исправление кода.
Т.е. для того, чтобы мне грамотно, хорошо и быстро писать код и делать программы мне нужно не только время и оборудованное рабочее место, но и возможность осуществления контроля качества моей работы. А для этого нужен еще один человек, чтобы произвести этот контроль. Мне интересно, как программисты-одиночки с этим справляются?
И теперь после прочтения этой главы, я поняла, почему open-sourse проекты не превращаются в свалку кода, и продолжают работать и развиваться. Исходники может посмотреть любой. Любой может не только внести изменения, но и посмотреть, что написал предыдущий программист. Т.е. пишущий точно знает, что его проконтролируют. Если не сейчас, то очень скоро потом. И это осознание заставляет проверять свой код.
Способов поддержать хорошее качество программ, работая дома, у меня пока два. Один - для программ для работы - показывать код, демонстрировать работу программы начальнику, исправлять найденные ошибки и недочеты. Второй - для своих проектов: выкладывать код на всеобщее обозрение, по возможности. Либо искать знакомых, имеющих время и силы просматривать мой код и указывать на недочеты.
понедельник, 5 мая 2014 г.
Качество По
Итак, Макконнелл перечисляет некоторые из характеристик качества ПО, внешние:
- корректность;
- практичность;
- эффективность;
- надежность;
- целостность;
- адаптируемость;
- правильность;
- живучесть.
- удобство сопровождения;
- гибкость;
- портируемость;
- возможность повторного использования;
- удобочитаемость;
- тестируемость;
- понятность.
Самое прикольное, что в этом списке есть требования, прямо противоречащие друг другу. Т.е. общего понятия качественного ПО не существует. Нужно для каждого проекта искать те характеристики качества, которым он должен удовлетворять. Автор даже предлагает таблицу, которая показывает, как разные показатели качества взаимодействуют между собой.
Контроль качества ПО - это планомерная и систематическая программа действий, призванная гарантировать, что система обладает желаемыми характеристиками.
Одна из эффективных методик повышения качества ПО - явное определение целевых внешних и внутренних характеристик. Контроль качества должен быть явным. Тестирование лишь один аспект контроля качества. Качество ПО повышается и от неформальных, и от формальных обзоров кода.
Макконелл привел таблицу эффективности обнаружения дефектов. Выводы из этой таблицы меня поразили. Я давно читала книгу про разработку через тестирование, и была уверена, что если бы могла легко протестировать автоматически визуальную часть приложения, в ней было бы меньше ошибок. Но оказалось, что блочное тестирование дает шанс выявить в среднем 30% ошибок. И что самыми хорошими результатами обладали формальные инспекции кода, моделирование, формальные инспекции проекта. По эффективности их обошло только масштабное (более чем в 1000 организаций) бета-тестирование. Вот так вот интересно.
Разные программисты находят разные дефекты - меня все время это удивляло на работе. Как так получалось, что у меня программа работает замечательно, а как только ею пользовался кто-то другой она выдавала ошибки.
Чтение кода способствует нахождению дефектов интерфейса, а функциональное тестирование - нахождению дефектов управляющих структур. Интересно. Но эту вещь я не проверяла.
Методики поиска дефектов лучше применять в комбинации. Одни методики помогут обнаружить одни дефекты, а другие - еще некоторые.
Я задумалась, почему мои институтские программы были хуже, чем рабочие. Скорее всего, дело было не только в том, что на учебу я тратила меньше времени. А еще и в том, что учебный код у меня никто не смотрел. И соответственно, внутри там было все хуже, чем в рабочем коде.
четверг, 1 мая 2014 г.
Как важны мелочи 2
Это добавление к посту о том, как важны мелочи.
воскресенье, 30 марта 2014 г.
Как важны мелочи
пятница, 28 марта 2014 г.
SQL в андроиде
понедельник, 17 марта 2014 г.
Пометки для себя
пятница, 14 марта 2014 г.
Переопределение и перегрузка
пятница, 7 марта 2014 г.
Конец про класс и про методы.
Минимизация сложности класса:
- Включайте в класс как можно меньше методов.
- Неявно сгенерированные методы, которые не нужны, блокируйте.
- Минимизируйте число разных методов, вызываемых классом.
- Избегайте опосредованных вызовов методов из других классов.
Инициализируйте по возможности все данные-члены!
Если нужен класс-одиночка - используйте синглтон.
Создавайте конструктор полного копирования, если сомневаетесь - для С++ это верно. Нужно ли это в Java, я не помню(.
Причины создания класса.
- Моделирование объектов реального мира.
- Моделирование абстрактных объектов.
- Снижение сложности.
- Изоляция сложности.
- Сокрытие деталей реализации.
- Ограничение влияния изменений.
- Упрощение передачи параметров в методы - если несколько методов используют одни и те же данные, вероятно, их нужно выделить в класс.
- Создание центральных точек управления.
- Облегчение повторного использования кода.
- Планирование создания семейства программ.
- Упаковка родственных операций.
- Выполнение специфического рода рефакторинга.
Методы.
Далее в книге идет целая глава, посвященная методам.Причины создания методов во многом такие же, как и причины создания классов. И кроме этого, есть еще несколько:
- снижение сложности;
- формирование понятия промежуточной абстракции;
- предотвращение дублирования кода;
- поддержка наследования - т.к. переопределить небольшой грамотно спроектированный метод проще, чем длинный и плохо спроектированный;
- сокрытие очередности действий;
- сокрытие операций над указателями - неочевидная для меня причина, но очень разумная и приводящая к простоте написания программы;
- улучшение портируемости;
- упрощение сложных булевых проверок - мне раньше казалось, что наличие таких проверок - это показатель "крутости" кода, но они практически нечитаемы после написания и отладки; поэтому и с этой причиной я согласна; попытаюсь впредь делать так;
- повышение быстродействия.
Цель - чтобы один метод эффективно решал одну задачу и больше ничего не делал.
Имена методов.
Имя метода должно ясно описывать все, что он делает. Т.к. ясно именовать методы в институте не учат, подробно пишу главу из книжки. Далее будет набор правил, позволяющих дать методу понятное имя. Общее правило - если метод трудно назвать, скорее всего, он плохо спроектирован.
- Описывайте все, что метод выполняет
- Избегайте невыразительных и неоднозначных глаголов
- Не используйте для различия методов исключительно номера (method1 (), method2 ()...)
- Не ограничивайте длину имени методов искусственными правилами - имя метода длиннее имени переменной; главной задачей имени является ясное и понятное описание сути метода.
- Для именования функции используйте описание возвращаемого значения.
- Для именования процедуры используйте выразительный глагол ( дополняя его объектом, если язык не ОО).
- Определяйте конвенции именования часто используемых операций.
- Дисциплинированно используйте антонимы. Т.к. это тоже одно из моих больных мест, пишу здесь часто используемые:
begin/end
create/destroy
first/last
get/put
get/set
increment/decrement
insert/delete
lock/unlock
min/max
next/previous
old/new
open/close
show/hide
sourse/target
start/stop
up/down
Желательно, чтобы длина метода была не более 150-200 строк(без комментариев и пустот), обычно метод занимает до 100 строк. Если метод хорошо спроектирован, он уложится в эти рамки (должен).
Функцию следует использовать тогда, когда главной целью метода является возврат конкретного значения, описываемого именем функции.
Про макросы.
Опять же, программируя на С++ я думала, что использовать макросы - это показатель крутости. Но их использование давало иногда такие ошибищи которые очень трудно было отследить и понять. Макконнелл не рекомендует использовать макросы, кроме как в условной компиляции (он ссылается в этом на Страуструпа, а тот, видимо, знает, что говорит)).
Итак, ура. Глава, посвященная методам обработана. Надеюсь, я буду это все использовать. Очень часто при чтении этой книги у меня возникают мысли: а, как просто-то, а я... Учиться мне еще и учиться...
суббота, 1 марта 2014 г.
Наследование. Продолжение.
- Убедитесь, что вы наследуете только то, что хотите наследовать. Не наследуйте реализацию только потому, что вы наследуете интерфейс. Если интерфейс класса не нужен, а нужна лишь реализация, то лучше включение, а не наследование.
- Не используйте имена непереопределяемых методов базового класса в производных классах.
- Перемещайте общие интерфейсы, данные и формы поведения на как можно более высокий уровень абстракции.
- С подозрением относитесь к классам, объекты которых создаются в единственном экземпляре. Исключение - "Одиночка".
- С подозрением относитесь к базовым классам, имеющим только один производный класс.
- С подозрением относитесь к класам, которые переопределяют метод, оставляя его пустым (убирая реализацию).
- Избегайте многоуровневых иерархий наследования.
- Предпочитайте полиморфизм, а не крупномасштабную проверку типов.
- Множественное наследование - "инструмент, который лучше большую часть времени хранить в гараже под замком". Может пригодится, но может и порождать ошибки (ромбовидная схема!).
Если несколько классов имеют общие данные, но не формы поведения, сделайте общий объект, который включите в эти классы.
Если несколько классов имеют общие формы поведения, но не данные, сделайте эти классы производными от общего базового класса, определяющего общие методы.
вторник, 25 февраля 2014 г.
Раздел "Вопросы проектирования и реализации".
Класс может содержать данные или другой класс. Это отношение "Включение".
- Реализуйте с помощью включения отношения "Содержит".
- В самом крайнем случае такое отношение может быть реализовано с помощью закрытого наследования - автор считает, что если получается только так, то это ошибка проектирования и что лучше всего еще раз подумать. Наверное, он прав. Я с таким на практике еще не сталкивалась.
- Настороженно относитесь к классам, содержащим более 7+\-2 данных-членов. Автор считает, что можно класс, содержащий много данных разбить на несколько классов, содержащих небольшое количество данных, и что это поможет упростить работу с данными. Опять же, нужно проверить на математике "Mittens".
"Цель наследования - создать более простой код, что достигается путем определения базового класса, идентифицирующего общие элементы двух или более производных классов."
- Реализуйте при помощи открытого наследования отношения "является". Если производный класс не будет полностью придерживаться контракта, наследоваться не надо.
- Проектируйте и документируйте классы с учетом возможности наследования или запретите его.
- Соблюдайте LSP: клиенты должны иметь возможность использования подклассов через интерфейс базового класса, не замечая никаких различий. Если программист, сделав наследование, забывает о деталях реализации наследников - все ОК. Если он должен думать о семантических различиях реализаций подклассов - наследование зло, тк. не способствует снижению сложности.
Инкапсуляция. Как сделать.
Итак, сейчас я читаю "Совершенный код" Макконнелла.
За сегодня я читала главы по инкапсуляции из раздела "Качественные интерфейсы классов".
"Без инкапсуляции абстракция обычно разрушается" - эта цитата определяет главный принцип сокрытия данных. Инкапсуляция - один из принципов управления сложностью проекта.
Автор предлагает несколько принципов, позволяющих добиться сокрытия методов и данных классов.
- Минимизировать доступность классов и их членов.
- Не предоставлять прямой доступ к данным-членам, а только к методам доступа к данным - с этим пунктом связано у меня больше всего ляпов в моих бывших и настоящих программах. В классах, занимающихся расчетами, обычно очень много данных, которые являются результатом работы. Например, в программе "Mittens". Делать к ним методы доступа я поленилась. А по данному принципу это было необходимо. Хотя, я до сих пор не хорошо понимаю, как можно программы расчетов чего-либо сделать полностью ОО. Мне кажется, не зря до сих пор большинство расчетов остались на фортране.
- Не включать в интерфейс класса детали реализации. В книге есть интересный пример для С++, как скрыть реализацию в заголовочном файле.class A{public: Aresult Funk() const; ...private: AEmplementation *a_emplementation;}В классе AEmplementation находится тот код, который не должен быть доступен классу, использующему класс А.
- Не делайте предположений о том, как класс будут использовать его клиенты. Все, что нужно, должно быть видно из интерфейса. Если какие-то значения нельзя указывать, то проверку значений не нужно отдавать классам клиентам.
- Избегайте использования дружественных классов. Я уже не помню точно, как их делают, т.к. ими не пользовалась. Автор указывает шаблон State(Состояние), как дисциплинированное использование таких классов. Шаблон не знаю. Нужно будет посмотреть потом.
- Не делать метод открытым только потому, что он использует открытые методы, посмотреть, укладывается ли он в абстракцию этого класса.
- Ценить легкость чтения кода выше, чем легкость его написания. Золотые слова! Можно их писать на мониторе, когда лениво печатать.
- Очень осторожно относится к семантическим (смысловым) нарушениям инкапсуляции.
- Остерегаться слишком жесткого сопряжения.
- Минимизировать доступность классов и их членов.
- Избегать дружественных классов
- Делать данные базового класса закрытыми, а не защищенными, чтобы наследники были меньше сопряжены с базовым.
- не включать данные-члены в открытый интерфейс класса.
- остерегаться семантических нарушений инкапсуляции.
- соблюдать "правило деметры" - А знает о Б, но не знает о том, какие методы Б вызывает.
вторник, 18 февраля 2014 г.
Программа для расчета варежек.
Поэтому, вчера я сделала так, чтобы программа считала варежку и отображала расчет на экране, решила, что если мне будет этого не хватать в процессе эксплуатации, я ее допишу, и выложила ее на диске.
Описание программы и инструкция здесь.
Из опыта разработки.
Списки у меня заработали. Разметку я научилась делать. Второй экран в этой проге был не нужен и я с ним не разбиралась. Как и с Intent.
Сейчас читаю Android 4 и Совершенный код. Бегаю между этими двумя книжками, читаю по чуть-чуть и не могу понять, что мне сейчас важнее и интереснее. Макконел легко читается. И у него есть дельные советы. Посмотрим, сколько полезного я извлеку из этой книги.
пятница, 7 февраля 2014 г.
Первое приложение готово
Один таймер я мучила 2.5 дня - это около 8 рабочих часов (когда дети спят и вечером).
Чуточку разобралась с хронометром(Chronometer).
Поняла, что переименовывать проект проще всего с помощью Refactor-> Rename.
И опять на меня находит паника "У меня не получается".
Скачать таймер можно здесь .
Выглядит так.
Назвала в честь Яны Франк. Я сейчас ее фанатка.
Таймер тихий. На заставке показывает время и отсчитывает рабочие минуты и секунды.
Можно запаузить.
Все просто.
Я учусь.
И кусочек кода:
// Хронометр. Отсчитывает время. Связваю его с виджетом
final Chronometer cr = (Chronometer)findViewById(R.id.chronometer1);
// Запускаю при создании программы
cr.start();
// Привязываю обработчик события тика таймера.
// Это новый класс реализующий интерфейс OnChronometerTickListener
cr.setOnChronometerTickListener(new OnChronometerTickListener(){
. . .
Продолжение следует.
воскресенье, 2 февраля 2014 г.
Записки ПД, часть 7.
Оказалось, что для эмулятора отладчик работает. Просто я не знала, как его включить! Я так обрадовалась, что могу посмотреть, что там внутри программы творится. Можно просто ставить точки прерывания. А можно писать в системный лог сообщения - Log.i и еще куча разных фильтров для сообщений. И все встроенное! Это одна из самых больших радостей за этот день!
Еще я стала переименовывать стандартные названия элементов интерфейса. Я так и не поняла, если eclipse создает два элемента TextView1, к какому он будет обращаться по id, когда мне понадобится привязать к нему объект.
Думаю купить книжку по программированию на андроиде, но оказалось, что их много. И отзывы те, что читала, они все какие-то не вдохноляющие. Придется идти в магазин и смотреть книжку на месте.
четверг, 30 января 2014 г.
Записки ПД, часть 6.
Я думала еще о том, как язык, на котором больше всего программируешь и который лучше знаешь, влияет на тебя и на то, как ты понимаешь разные задачи. Я имею самый большой опыт программирования на С++, и все способы, все шаблоны, все действия, которые я могу сделать - они в первую очередь выполнимы на этом языке, а потом уже на других. Для меня был откровением Perl, потому что на нем нельзя было нормально делать математику, но зато легко было вычленять пути файлов, разбирать строки. На нем я делала какие-то нужные мне утилиты, и это было легко. Я бы не смогла то же самое сделать на С++, там эти изящные программы повисли бы мертвым грузом и тяжелым неудобочитаемым кодом. Я читала умные книжки во время учебы, и мне запомнилась одна фраза, что для развития программисту необходимо хотя бы каждый год изучать новый язык программирования. Я тогда начала считать, и у меня количество языков, в которых я пыталась разобраться, было явно меньше количества лет практики программирования.
Когда, несколько месяцев назад, я пыталась вспомнить JavaScript, я поняла, что не слишком часто используемые навыки очень легко забываются. Кусок пробного кода я смогла написать лишь найдя мануал. Стало так грустно. Я думала, что единожды выученный язык - это навсегда. Оказалось, что чтобы это было так, нужно практиковать его до такой степени, чтобы он и во сне от зубов отлетал.
Записки ПД, часть 5
По совету, нашла курс интуита по программированию под Android. Посмотрела третью лекцию и испугалась. Там все по другому. Все по другому реализовано! Хотя, может и примерно так же. Но все новое для меня. Один класс Intent чего стоит! Я ничего не понимаю...
Сегодня чисто по лекции создала приложение, по которому происходит переход из одного окна в другое. Вроде работает. Но почему-то несколько первых запусков закончились крахом эмулятора. Хотя, может я слишком рано кликала по нему мышкой. Он медленно грузится, а когда в активном эмуляторе кликать мышкой или клавиатурой, он почему-то воспринимает это как вмешательство в загрузку.
В конце концов переходы удались.
А потом проснулись дети. И все. Программирование кончилось.
вторник, 28 января 2014 г.
Записки ПД, часть 4.
Очень боюсь начинать новый проект. Мне переделывать за кем-то проще, чем с самого начала писать самой. Я все время боюсь наблюдать, как он разрастается с одной строки до большой системы файлов, ссылок, классов, проектов... Жуть. А ведь все начинается так хорошо, так понятно. А становится какой-то ужас!
Пока пишу на бумаге структуры данных, необходимые функции, общий вид программы. Вроде, все понятно и все хорошо, и все довольно просто.
Пока выходит два окна, "Общий вид" и "Редактирование записи", и одно диалоговое на подтверждение удаления.
Хранить данные между запусками буду в двух файлах. Связываться с сервером не буду. Вроде это не надо. Если это делать, то я закопаюсь, т.к. ни разу этого не делала, а Мишке такая фишка не очень нужна - он везде с одним телефоном.
Нужно узнать стандартный тип хранения даты в Java.
Итак, до следующего раза.
Записки программиста-домохозяйки. Часть 3.
Создала приложение под андроид и все сначала... Очень необычное чувство, когда делаешь программу и не можешь точно сказать, за что отвечает таекущая настройка и что получится в результате.
Из плюсов - для создания разметки вида окна необязательно писать xml-код. Можно все сделать вживую - кнопки посмотреть, текст пододвинуть...
android:src не действует. Картинка не грузится.
Код функции GetTemp не работает. Сайт, с которого он брал информацию изменился, и все полетело. Но почему то эта функция на эмуляторе выдает исключение, а на компе просто начальное значение. Непонятно. Да, кстати, дебаг на виртуальном устройстве не работает.
Теперь я на перепутье. Вроде как, приложение скомпилировалось и запустилось. Я посмотрела, что эмулятор работает. И что даже такое левое можно загрузить и посмотреть с телефона. То ли дальше его до ума доводить. То ли свое уже делать...
понедельник, 27 января 2014 г.
Записки программиста-домохозяйки. Часть 2.
Вчера вечером попросила мужа достать с антресоли книжку Шилдта и перед сном читала детям первые главы. Детям не понравилось. Но книга написана легким языком, читать приятно. Хорошо что не успела ее никому отдать и не выкинула.
Вчера же пробовала собрать тестовый проект из статьи. Ничего не вышло. Проект не собирается, сразу куча ошибок. Не знаю, с какой стороны их разматывать. Поэтому решила, что его пока трогать не буду. Начну по книжке, с азов, с HelloWorld.
Записки программиста-домохозяйки
Я решила снова начать программировать и сделать ему этот планировщик.
Что имеем: программист, с трехлетним стажем декретного отпуска. Нужно сделать программу для смартфона на андроиде. Есть ноутбук на кухне. Есть двое детей. Вот и все.
Чтобы понять, с какой стороны начинать, я пишу в поисковике фразу "как программировать под андроид". Меня выносит на хабр. Пробежала глазами статью и пытаюсь делать все по ней. Устанавливаю Eclipse Standart. Он не работает без JDK. Ищу ее, распаковываю, и думаю, что делать дальше. Она не ставится. Это просто файлы. Беру этот каталог, кидаю в каталог, где лежит eclipse.exe и переименовываю в jre. Работает.
Дальше скачиваю и ставлю android sdk.Большое. Сначала качается оболочка, потом при установке, добираются необходимые библиотеки. В первую скачку ноут заснул, недоходядо конца загрузки. И виртуальный андроид не работал. Поискала в интернете, нашла проблему, перекачала библиотеки.
На то. чтобы сделать среду разработки ушло три дня.