Ребят, но для начала надо выучить все эти команды. А в обычном интерфейсе иконки на кнопrках как минимум логичны и есть подсказка при наведении. Если для того что бы мне писать на языке мне кроме того что изучать язык надо еще в два раза дольше зубрить команды редактора — то мне не нужен такой редактор. А если везде внедрять такой принцип как предлагает автор — то вперед -> назад к ДОСу
От себя замечу, может кому-то пригодится мой опыт.
После того как понял, что консольная тулза это прежде всего инструмент автоматизации и только во вторую очередь «молоток» для ручного применения. Исходя из этого факта пришел к выводу, что нужно выдавать не совсем в человеко-читаемом виде, а в человеко-читаемом формате, но удобном для парсинга другими тулзами. Таким форматом для меня сейчас является JSON, его применение парсинг на Python просто песня, 3-5 строки + строки на обработку исключений. При этом JSON достаточно легко читается человеком, если конечно соблюсти pretty-print.
Наконецто первая толковая статья, которая трезво определяет место NoSQL, без лишнего хайпа. Вам жирнейший плюс за перевод.
Я лююблю сравнивать реляционные базы данных с UNIX. Обе технологии — долгожители, пережиили не одно поколение смены других технологий и все еще имеют широкое применение. Причниа этого — настолько же банальна, насколько и проста, изза чего многие падкие на новое и блестящее любят вытирать об них ноги. Причина эта в вашем заголовке — гибкость.
Юникс состоит из множества утилит которые делают свое дело и делают его хорошо. И под конкретную задачу вы на ходу комбинируете нужные вам утилиты, чтобы получить необходимый результат, поэтому тот кто овладел командной строкой за 5 минут может решить нетривальные одноразовые задачи, для которых обычному пользователю нужны специальный софт.
Аналогично с БД, только уже на уровне данных. Таблицы — это ваша «файловая системв», а язык SQL — ваши sed, awk, ls, cp итд. NoSQL — это «специальная программа под конкретную задачу». Поэтому каждое NoSQL решение полезно вам в тех случаях, которые подходят под определенный круг задач. Шаг влево, шаг вправо — вам нужна еще одна специальная утилита для каждой новой конкретной задачи, в то время как SQL и логичная схема дают вам универсальный инструмент.
Например, как аналог, такой пример — возможно вы сможете установить готовую убунту из готового образа на Amazon EC2, потому что ктото позаботился о специализированном решении, но если вам понадобится смигрировать готовую систему на каком нибуть хитром или сильно кастомизированном дистрибутиве на EC2, вам понадобится более универсальный инструмент.
Возможность комбинировать данные из разных схем — преимущество, которое не позволит SQL исчезнуть никуда и никогда, как бы сильно этого кому то не хотелось, так же как и юникс, он может лишь эволюционировать в более совершенный интструмент, а удел NoSQL — нишевые задачи — всегда таким был, всегда таким и будет, просто зоопарк NoSQL-моделей будет расти.
Если кому то интересны еще «неправославные» аналогии, — такое же место у XML vs JSON. XML — универсальный расширяемый текстовый формат, находящий применение буквально везде и применимый буквально ко всему. JSON — специализированное решение, упрощенный формат под конкретные задачи представления обьектов, где не требуется строгая валидация.
Знакомые, которые отличают вслепую lossless от lossy у меня есть.
Видел достаточно подобных заявлений, но ни разу не встречал подтверждений. Если вам не сложно, дайте вашим знакомым послушать 3 файла и определить, где оригинал, а где lossy: test1.wavtest2.wavtest3.wav. Один из этих файлов содержит оригинальный фрагмент, два других — закодированные в Ogg Vorbis 256kbps и 500kbps и декодированные обратно. После я опубликую в каком файле оригинал, а в каких — lossy. Если считаете, что фрагмент неудачный, можно провести эксперимент на другом подходящем материале.
Реальность, увы, ваши «эротические фантазии» не подтверждает. Ни в части «стремительно», ни даже в вообще «расти».
> 5% это только пользователи
На самом деле «только пользователи» даже еще 1% никак не могут перепрыгнуть. Ссылка на Statcounter выше, где как Linux учтены комичные 0,78%, на грани статпогрешности.
Вот я могу свои утверждения подтвердить документальными исследованиям вопроса, а вы?
PS. Наверное рост с 0,25% до 1% это, конечно, будет «стремительный рост в четыре раза», тут не поспоришь. Ну а все-таки, будут хотя бы такие цифры?
Такие чипы давно существуют, например в Питере разработали, для компании Mstar
Он во многие навигаторах используется. Например в этом sdelanounas.ru/blogs/8367/
Работают они нормально.
Разоблачения всякие можно у меня почитать, с коментариями разрабочиков
Вы действительно думаете, что если у человека другое мнение, то он должен извинятся? Лол, да.
Я ценю тонны вашей копипасты, но цыплят по осени считают, так что судить SSJ по 3ем самолётам никак нельзя, тем более, что SSJ сделали в фирме, которая вообще никогда не занималась проектированием гражданских самолётов (в отличие от того же ЦАГИ, который по факту утерян для России сейчас). Опять же успех димлайнера тоже сейчас никак нельзя оценить, вполне это может стать epic fail, хотя доверие к боингу несколько выше.
Про китайский айфон, конечно, супер забавно. То что Apple заказывает сборку в Китае уж никак не делает его китайским, а Китай телефонной супердержавой. Да и приписывать мне то, что я никогда не говорил — это не женская, это вообще никакая не логика. Прощайте.
После того как понял, что консольная тулза это прежде всего инструмент автоматизации и только во вторую очередь «молоток» для ручного применения. Исходя из этого факта пришел к выводу, что нужно выдавать не совсем в человеко-читаемом виде, а в человеко-читаемом формате, но удобном для парсинга другими тулзами. Таким форматом для меня сейчас является JSON, его применение парсинг на Python просто песня, 3-5 строки + строки на обработку исключений. При этом JSON достаточно легко читается человеком, если конечно соблюсти pretty-print.
Я лююблю сравнивать реляционные базы данных с UNIX. Обе технологии — долгожители, пережиили не одно поколение смены других технологий и все еще имеют широкое применение. Причниа этого — настолько же банальна, насколько и проста, изза чего многие падкие на новое и блестящее любят вытирать об них ноги. Причина эта в вашем заголовке — гибкость.
Юникс состоит из множества утилит которые делают свое дело и делают его хорошо. И под конкретную задачу вы на ходу комбинируете нужные вам утилиты, чтобы получить необходимый результат, поэтому тот кто овладел командной строкой за 5 минут может решить нетривальные одноразовые задачи, для которых обычному пользователю нужны специальный софт.
Аналогично с БД, только уже на уровне данных. Таблицы — это ваша «файловая системв», а язык SQL — ваши sed, awk, ls, cp итд. NoSQL — это «специальная программа под конкретную задачу». Поэтому каждое NoSQL решение полезно вам в тех случаях, которые подходят под определенный круг задач. Шаг влево, шаг вправо — вам нужна еще одна специальная утилита для каждой новой конкретной задачи, в то время как SQL и логичная схема дают вам универсальный инструмент.
Например, как аналог, такой пример — возможно вы сможете установить готовую убунту из готового образа на Amazon EC2, потому что ктото позаботился о специализированном решении, но если вам понадобится смигрировать готовую систему на каком нибуть хитром или сильно кастомизированном дистрибутиве на EC2, вам понадобится более универсальный инструмент.
Возможность комбинировать данные из разных схем — преимущество, которое не позволит SQL исчезнуть никуда и никогда, как бы сильно этого кому то не хотелось, так же как и юникс, он может лишь эволюционировать в более совершенный интструмент, а удел NoSQL — нишевые задачи — всегда таким был, всегда таким и будет, просто зоопарк NoSQL-моделей будет расти.
Если кому то интересны еще «неправославные» аналогии, — такое же место у XML vs JSON. XML — универсальный расширяемый текстовый формат, находящий применение буквально везде и применимый буквально ко всему. JSON — специализированное решение, упрощенный формат под конкретные задачи представления обьектов, где не требуется строгая валидация.
Вы делаете это потому что хотите.
А все остальное — это попытка оправдать воровство.
AMD хочет на сервера, которые чуть менее, чем полностью под контролем Intel.
> 5% это только пользователи
На самом деле «только пользователи» даже еще 1% никак не могут перепрыгнуть. Ссылка на Statcounter выше, где как Linux учтены комичные 0,78%, на грани статпогрешности.
Вот я могу свои утверждения подтвердить документальными исследованиям вопроса, а вы?
PS. Наверное рост с 0,25% до 1% это, конечно, будет «стремительный рост в четыре раза», тут не поспоришь. Ну а все-таки, будут хотя бы такие цифры?
Он во многие навигаторах используется. Например в этом sdelanounas.ru/blogs/8367/
Работают они нормально.
Разоблачения всякие можно у меня почитать, с коментариями разрабочиков
antiliberast.livejournal.com/220046.html
antiliberast.livejournal.com/220823.html
Я ценю тонны вашей копипасты, но цыплят по осени считают, так что судить SSJ по 3ем самолётам никак нельзя, тем более, что SSJ сделали в фирме, которая вообще никогда не занималась проектированием гражданских самолётов (в отличие от того же ЦАГИ, который по факту утерян для России сейчас). Опять же успех димлайнера тоже сейчас никак нельзя оценить, вполне это может стать epic fail, хотя доверие к боингу несколько выше.
Про китайский айфон, конечно, супер забавно. То что Apple заказывает сборку в Китае уж никак не делает его китайским, а Китай телефонной супердержавой. Да и приписывать мне то, что я никогда не говорил — это не женская, это вообще никакая не логика. Прощайте.