Я не специалист по 3D печати, но по статьям на Хабре кажется что качество там не очень высокое. И можно ли напечатать клавиатуру со всей ее механикой?
Хотя конечно не спорю, при наличии возможности напечатать было бы лучше — тем более данный корпус для современной мобильности все-же великоват.
Наоборот — что можно сделать на старом железе? Ничего, разве что запустить какой-то чудом сохранившийся и сейчас уже бесполезный старый софт, посмотреть на результат и убрать обратно в кладовку. А на современном железе можно сделать многое, в том числе полноценно работать.
Вот как раз корпуса и клавиатуры у старого железа отличные, не то что сейчас абсолютно одинаковые сенсорные доски:) Не знаю возможно ли в домашних условиях подобным образом обновлять более мелкие мобильные устройства с оригинальными форм-факторами. Но было бы интересно, если бы какой-то умелец нечто подобное сделал.
Собственно визуальное программирование — утопия. Программы очень непохожи на электронные схемы, и приблизить их не получится ввиду принципиальной императивности кода. Возможно, для чисто функционального языка что-то и можно сделать…
Но можно совершенствовать сами языки программирования и среды разработки.
Я уже писал, что для выразительности кода не хватает операторных символов (а их набор ограничен ASCII ввиду его общедоступности на любой клавиатуре мира). Это скорее всего уже нереально изменить.
А вот сам дизайн языков должен быть более похожий на «языки разметки», то есть такой, чтобы среды разработки могли максимально легко проводить парсинг «на лету» и трансформировать части кода в какие-то визуализации.
Это не тянет на парадигму программирования (такую как ООП, ФП и т.д.). Максимум — на паттерн проектирования. И как паттерн это всегда использовалось, со времен появления программирования как такового.
Все-таки непонятно что такое «автоматное программирование» и «switch-технология» и чем это отличается от обычных машин состояний, которые довольно часто применяются в программах практически на любом языке?
Было бы интересно появление статьи на Хабре непосредственно про эту технологию.
Вкладок немного, не больше десятка. Да и долго не держу — решу вопрос, закрываю. Несколько браузеров для разных задач и профилей, чтобы не было пересечений.
А интересные полезные страницы просто сохраняю в mhtml. Иногда, когда их накопится достаточное количество, сортирую эти файлы по темам.
Но вообще, проблема со вкладками, сам способ работы с информацией, приводящий к сотням вкладок, в очередной раз раз показывает всю кривизну существующего централизованного интернета и способов работы с ним, всю его заточенность на зарабатывание бабла на баннерах, а не на формирование Единой Базы Знаний Человечества.
Я бы предпочел, чтобы любая интересная мне страница (или и пост в соцсети, или любой другой более-менее самодостаточный контент) сохранялась в локальной базе автоматически (с возможной синхронизацией, но без потери данных в случае если оригинальный источник будет удален), чтобы ей можно было назначить место в дереве базы знаний и дополнительные теги, чтобы она участвовала в поиске, чтобы к ней (в том числе к отдельным частям страницы) можно было писать заметки и комментарии, чтобы можно было через p2p получить рекомендации по связанным страницам от других пользователей, которые тоже добавили ее в свои хранилища…
Я имею в виду скажем словари для Anki или подобных программ. Да, кстати похожесть английских слов на русские, или удачные мнемоники — тоже хорошая идея для ассоциаций.
Кстати, а существуют ли словари (англо-русские например), в которых слова объединены в ассоциативную сеть по различным признакам:
* похожести звучания
* похожести написания
* общей этимологии (как licence, leisure и pleasure в статье)
и тому подобное?
Вообще это чрезвычайно интересно — слова, у которых есть «интересная история», запоминаются гораздо лучше чем просто тупое заучивание пар «слово на английском-слово на русском». Можно легко запоминать целые кластеры слов с общей этимологией, опираясь именно на этимологию как на осмысленный и интересный контент. Можно изучать сразу несколько языков — ведь на самом деле очень многие слова имеют общее происхождение.
Цивилизация это не раковая опухоль, чтобы забивать собой всю галактику. Цивилизация стремится не к неограниченной экспансии, а к достижению равновесия. Весьма вероятно, что грандиозная космическая деятельность для этого просто не нужна. Постижение фундаментальных законов физики может открыть перед цивилизацией возможности, по сравнению с которыми колонизация космоса так же бессмысленна, как скажем постановка на кадастровый учет каждой песчинки в пустыне. Вообще, мысли о галактических империях напоминают мне Лондон, погребенный под кучами конского навоза. Т.е. некорректную футурологическую экстраполяцию без понимания сути явлений.
Впрочем, нам до всего этого еще далеко.
Отличная тема! Я об этом много думал и сейчас иногда думаю.
В общем, если брать пример с книгами, то наверное базовая иерархия все-же нужна, но и теги нужны тоже. Например, «Программирование» и «Qt» это не равноправные теги: «программирование» однозначно тег верхнего уровня, «Qt» — вложенный тег (причем между ними еще должен быть тег «C++»). Однако часто бывают ситуации когда теги действительно равноправны. Наиболее очевидный пример — статьи со сравнением двух технологий. Также — некая взаимосвязь технологий (когда одна используется для другой). Книги по программированию микроконтроллеров относятся одинаково и к программированию на конкретном языке (скажем Си), и к микроконтроллерам конкретного типа. Книги по программированию под некую ОС (Windows, Linux) — одинаково к программированию на языке (скажем С++) и программированию под ОС.
Проблема еще в современных файловых системах. Они совсем не базы данных. Хотя где-то там, внутри, у них есть какие-то дополнительные возможности типа хардлинков, симлинков и файловых потоков, этого все равно недостаточно. Но некоторые задачи можно решить с их помощью. От иерархической файловой системы все равно никуда не деться, и поддерживать на диске порядок в виде документов, сгруппированных в иерархической системе папок — это правильно. В Либгене например имена книг — это просто md5 хеши, все файлы лежат в куче, и найти что-то без софта просто невозможно. ИМХО, это не есть хорошо, это просто снижает надежность системы — если софт или база сломается, то найти что-либо не удастся в принципе (и вот кстати отличный пример применения файловых потоков или расширенных атрибутов — все хеши должны храниться именно там, а не в имени файла; также как и вся метаинформация типа автора, года издания и языка).
Ну и есть еще множество аспектов, тут надо целую статью писать, в комментарий не влезет. Сейчас, вспоминая свои заметки по этому вопросу, я отмечу лишь мысль о необходимости объединения подходов с иерархией и с тегами.
Базовая иерархия нужна — у каждого документа есть базовое место в ФС («главный тег»);
Если у документа два равноправных места в ФС, то применяется хардлинк;
Также у документа есть теги, позволяющие более точно описать документ, построить граф связей, определить место документа в поисковой выдаче и т.д.
Единственное правильное направление — децентрализованная сеть, в которой происходит непрерывный обмен как документами (книги, статьи, разумеется только то что пользователь расшарил) так и метаинформацией о них. В этом случае метаинформация никогда не пропадет — она будет храниться оффлайн у тысяч, а то и миллионов пользователей, и силами этих пользователей постоянно обновляться и совершенствоваться.
То что драйвера семерки не работают в десятке это кстати тоже проблемы модульности. Как и то что драйвера семерки или десятки не работают в линуксе.
Да, это проблемы другого уровня (отсутствие стандартизированного на уровне ISO интерфейса драйвера, отсутствие возможности автогенерации адаптера драйвера для конкретной ОС по метаинформации, хранящейся в драйвере).
Я например узнал очень полезную информацию — что оказывается в США есть люди, сохраняющие терабайтные архивы с разных сайтов и соцсетей. Я думал, что такие энтузиасты-романтики сейчас уже не встречаются.
Все это наводит на мысль о недостаточной модульности ядра и недостаточной поддержке модульности со стороны языка Си. Зачем удалять, если оно работает? Любой новый код по идее вообще никак не должен влиять на старый.
Я не против чтобы было и 12 дюймов. Такой планшет с «альбомным» захватом и небольшой клавиатурой по бокам экрана, для набора преимущественно большими пальцами рук. Но вполне можно и меньше чем 12. Если ОС специальная (тот же Андроид), то и софт для такой железки специальный. Полноценную винду или линукс никто запускать там не собирается.
Реальные сценарии использования для меня — это главным образом чтение и редактирование текстов.
Было бы хорошо, если бы такие штуки как Atari Portfolio (или скажем Samsung Q1 Ultra, мне больше нравится его концепция клавиатуры для ультрапортативного использования, т.е. «на ходу») производили на современном железе и современных ОС.
Но вот нет.
Я не так давно озадачился гораздо более простой штукой: смартфоном с торцевой камерой (т.е. с дополнительной камерой, расположенной на переднем торце, как ИК-светодиод у пульта ДУ). И даже этого нет.
Фантазия у разработчиков железа совсем иссякла.
Хотя конечно не спорю, при наличии возможности напечатать было бы лучше — тем более данный корпус для современной мобильности все-же великоват.
Вот как раз корпуса и клавиатуры у старого железа отличные, не то что сейчас абсолютно одинаковые сенсорные доски:) Не знаю возможно ли в домашних условиях подобным образом обновлять более мелкие мобильные устройства с оригинальными форм-факторами. Но было бы интересно, если бы какой-то умелец нечто подобное сделал.
Но можно совершенствовать сами языки программирования и среды разработки.
Я уже писал, что для выразительности кода не хватает операторных символов (а их набор ограничен ASCII ввиду его общедоступности на любой клавиатуре мира). Это скорее всего уже нереально изменить.
А вот сам дизайн языков должен быть более похожий на «языки разметки», то есть такой, чтобы среды разработки могли максимально легко проводить парсинг «на лету» и трансформировать части кода в какие-то визуализации.
Было бы интересно появление статьи на Хабре непосредственно про эту технологию.
А интересные полезные страницы просто сохраняю в mhtml. Иногда, когда их накопится достаточное количество, сортирую эти файлы по темам.
Но вообще, проблема со вкладками, сам способ работы с информацией, приводящий к сотням вкладок, в очередной раз раз показывает всю кривизну существующего централизованного интернета и способов работы с ним, всю его заточенность на зарабатывание бабла на баннерах, а не на формирование Единой Базы Знаний Человечества.
Я бы предпочел, чтобы любая интересная мне страница (или и пост в соцсети, или любой другой более-менее самодостаточный контент) сохранялась в локальной базе автоматически (с возможной синхронизацией, но без потери данных в случае если оригинальный источник будет удален), чтобы ей можно было назначить место в дереве базы знаний и дополнительные теги, чтобы она участвовала в поиске, чтобы к ней (в том числе к отдельным частям страницы) можно было писать заметки и комментарии, чтобы можно было через p2p получить рекомендации по связанным страницам от других пользователей, которые тоже добавили ее в свои хранилища…
* похожести звучания
* похожести написания
* общей этимологии (как licence, leisure и pleasure в статье)
и тому подобное?
Вообще это чрезвычайно интересно — слова, у которых есть «интересная история», запоминаются гораздо лучше чем просто тупое заучивание пар «слово на английском-слово на русском». Можно легко запоминать целые кластеры слов с общей этимологией, опираясь именно на этимологию как на осмысленный и интересный контент. Можно изучать сразу несколько языков — ведь на самом деле очень многие слова имеют общее происхождение.
Я имел в виду оффлайн хранение данных и обмен метаинформацией в p2p сети.
Впрочем, нам до всего этого еще далеко.
В общем, если брать пример с книгами, то наверное базовая иерархия все-же нужна, но и теги нужны тоже. Например, «Программирование» и «Qt» это не равноправные теги: «программирование» однозначно тег верхнего уровня, «Qt» — вложенный тег (причем между ними еще должен быть тег «C++»). Однако часто бывают ситуации когда теги действительно равноправны. Наиболее очевидный пример — статьи со сравнением двух технологий. Также — некая взаимосвязь технологий (когда одна используется для другой). Книги по программированию микроконтроллеров относятся одинаково и к программированию на конкретном языке (скажем Си), и к микроконтроллерам конкретного типа. Книги по программированию под некую ОС (Windows, Linux) — одинаково к программированию на языке (скажем С++) и программированию под ОС.
Проблема еще в современных файловых системах. Они совсем не базы данных. Хотя где-то там, внутри, у них есть какие-то дополнительные возможности типа хардлинков, симлинков и файловых потоков, этого все равно недостаточно. Но некоторые задачи можно решить с их помощью. От иерархической файловой системы все равно никуда не деться, и поддерживать на диске порядок в виде документов, сгруппированных в иерархической системе папок — это правильно. В Либгене например имена книг — это просто md5 хеши, все файлы лежат в куче, и найти что-то без софта просто невозможно. ИМХО, это не есть хорошо, это просто снижает надежность системы — если софт или база сломается, то найти что-либо не удастся в принципе (и вот кстати отличный пример применения файловых потоков или расширенных атрибутов — все хеши должны храниться именно там, а не в имени файла; также как и вся метаинформация типа автора, года издания и языка).
Ну и есть еще множество аспектов, тут надо целую статью писать, в комментарий не влезет. Сейчас, вспоминая свои заметки по этому вопросу, я отмечу лишь мысль о необходимости объединения подходов с иерархией и с тегами.
Базовая иерархия нужна — у каждого документа есть базовое место в ФС («главный тег»);
Если у документа два равноправных места в ФС, то применяется хардлинк;
Также у документа есть теги, позволяющие более точно описать документ, построить граф связей, определить место документа в поисковой выдаче и т.д.
Да, это проблемы другого уровня (отсутствие стандартизированного на уровне ISO интерфейса драйвера, отсутствие возможности автогенерации адаптера драйвера для конкретной ОС по метаинформации, хранящейся в драйвере).
Реальные сценарии использования для меня — это главным образом чтение и редактирование текстов.
Но вот нет.
Я не так давно озадачился гораздо более простой штукой: смартфоном с торцевой камерой (т.е. с дополнительной камерой, расположенной на переднем торце, как ИК-светодиод у пульта ДУ). И даже этого нет.
Фантазия у разработчиков железа совсем иссякла.