Чтобы настроить и установить все необходимое на любимую читалку Amazon Kindle Paperwhite
Дак, там уже и так все настроено, и есть все необходимое — бери и читай. Разве что wi-fi настроить и слинковать с amazon'овской учеткой. Еще можно установить словарь англо-русский.
Вот интересно, насколько часто востребованы: калькулятор, блокнот, игры, пеинтер… Это же ридер, а не планшет.
А почему «теперь»? Это же не новая «фича», на сколько я заню.
Есть плагины для браузеров, например, блокирующие межсайтовые запросы (можно по спискам белый/черный). Забавно видеть, при использовании подобного плагина, на сколько сайты сейчас завязаны на внешние ресурсы — многие просто оказываются не рабочими без посторонних ресурсов.
А какого функционала вам не хватает в Marlight? Действительно интересно, ибо у вас уже есть user experience с LIFX. В моем представлении выглядит так: купить, установить, пару вечером поиграться с цветом, настроить удобную цветовую температуру, а дальше использовать диммирование да включение/выключение по каналам…
Более привлекательным выглядит вот этот проект: Mr Beam — больше формат рабочей поверхности; не только гравировка, но и резка; больше список поддерживаемых материалов (хотя тут, думаю, играют роль настройки режима гравировки/резки).
Встречал случаи, когда выкладывают в открытый доступ одну из глав книги (из середины). Одной главы вполне хватало, чтобы определиться понятно ли изложение автора, и нужна ли информация из конкретной книги.
Хм, у Вас был стресс (из-за большого количества звонков), а из-за внезапной асоциализации Вы временно отстранились от этого раздражителя. Вы себя обманываете — Вы не перестали пользоваться сотовым телефоном — телефон в машине; функции секретаря, выполняемые женой; скайп… Может быть стоило пересмотреть политику звонков, аки завести рабочий телефон; начать пользоваться голосовой почтой; перевести решения определенных вопросов в почту/личное общение; не отвечать на каждый звонок (режим пользования для состояния «на связи»); обговорить правила звонков с коллегами и близкими/друзьями?
А то история совершенно не про то, о чем гласит заголовок, получается.
Используйте #ifdef для кода под конкретную платформу.
Ох, и вредный же это совет… Ибо через некоторое время даже небольшой код превращается в не читаемый адик. (есть опыт работы с большим проектом под несколько платформ и написания небольшой библиотеки для 2х платформ) Решается это на уровне проектирования — создание общего интерфейса для классов, а платформо-зависимая часть кода выноситься в отдельные файлы, там где нужно применяются фабричные методы, которые разруливают создание объектов под текущую платформу. В таком случае кол-во #ifdef'ов можно свести к минимуму, ибо ими будет обернуты #include'ы подключающие нужные заголовочные файлы. Такой подход, с выносом platform-specific кода в отдельные файлы, очень помогает упростит понимание структуры программы и поддержку кода.
Возможно где-то скапитанил.
Отвлеченный режим — это полноэкранный режим без лишних элементов гуйни. У меня в этом режиме настроено отображение только двух панелей для редактирования, миникарты для них и табы.
Еще ко всему в файл настройки проекта можно включить настройки самой среды редактора, бывает довольно полезно.
Хм, а зачем один редактор превращать в другой? Почему бы переходя на другой инструмент не использовать его возможности, замест попыток получить тот же N++? Толку тогда от перехода?
Кроссплатформенность (может кому не актуально, но сам успел почти за год использования поработать на всех трех основных операционках, в последнее время постоянно использую на двух осях — win & mac), и на всех оперционках редактор ведет себя ожидаемо и привычно. Наличие «отвлеченного» режима. Наличие проектов и нечеткого поиска по всем файлам проекта и текущему. Плюс ко всему довольно гибкая настройка проектов. Отсутствие необходимости сохранять файлы — довольно часто открыто пара временных файлов для заметок по структуре и тд — цикл жизни их относительно краток, чтобы сохранять, а потом чистить файловую систему, при закрытии/открытии редактора он запускается в том состоянии в котором был закрыт (это гениальное решение! имхо так и должны работать редакторы, да и не только они). Наличие текстового конфига, а не ужасно-неудобной гуйни для настройки. Доступность функционала посредством командной палитры (нет необходимости запоминать шоткаты для редко используемых функций). Встроенный Python (и консоль для него).
Что немного огорчает, так это отсутствие гибкого автокомплита (там есть автокомплит в рамках файла), хотя для используемого для разработки яп нету редактора с нормальным автокомплитом.
У вас не определено, что есть «идеальный» игровой движок в вашем понимании. Мотивация разработки? А так же область его применения? Насколько понял — web?
> Сначала мы придумаем и напишем 2-3 типовых игры на «идеальном» движке, т.е. сначала будет создано само приложение, а уже потом под его код будет писаться движок.
То есть пытаетесь создать конструктор шаблонных игр?
Да, таких довольно много. И самое печальное, что довольно увесистая часть так и остается на этом уровне… А потом смотришь исхода какой-нибудь игры и не веришь, что такое вообще возможно писать…
Хм, а как решена проблема с отоплением салона? Всегда было интересно, как это решается в электромобилях, ладно там Калифорния (да, и большая часть страны заходящего солнца) — им это не актуально. Если питать обогреватель от основного источника питания, то это же очень большой расход энергии…
Дак, там уже и так все настроено, и есть все необходимое — бери и читай. Разве что wi-fi настроить и слинковать с amazon'овской учеткой. Еще можно установить словарь англо-русский.
Вот интересно, насколько часто востребованы: калькулятор, блокнот, игры, пеинтер… Это же ридер, а не планшет.
Есть плагины для браузеров, например, блокирующие межсайтовые запросы (можно по спискам белый/черный). Забавно видеть, при использовании подобного плагина, на сколько сайты сейчас завязаны на внешние ресурсы — многие просто оказываются не рабочими без посторонних ресурсов.
А то история совершенно не про то, о чем гласит заголовок, получается.
Ох, и вредный же это совет… Ибо через некоторое время даже небольшой код превращается в не читаемый адик. (есть опыт работы с большим проектом под несколько платформ и написания небольшой библиотеки для 2х платформ) Решается это на уровне проектирования — создание общего интерфейса для классов, а платформо-зависимая часть кода выноситься в отдельные файлы, там где нужно применяются фабричные методы, которые разруливают создание объектов под текущую платформу. В таком случае кол-во #ifdef'ов можно свести к минимуму, ибо ими будет обернуты #include'ы подключающие нужные заголовочные файлы. Такой подход, с выносом platform-specific кода в отдельные файлы, очень помогает упростит понимание структуры программы и поддержку кода.
Возможно где-то скапитанил.
Еще ко всему в файл настройки проекта можно включить настройки самой среды редактора, бывает довольно полезно.
Что немного огорчает, так это отсутствие гибкого автокомплита (там есть автокомплит в рамках файла), хотя для используемого для разработки яп нету редактора с нормальным автокомплитом.
> Сначала мы придумаем и напишем 2-3 типовых игры на «идеальном» движке, т.е. сначала будет создано само приложение, а уже потом под его код будет писаться движок.
То есть пытаетесь создать конструктор шаблонных игр?