DE
но почему?
Size: a a a
2019 August 07
OI
но почему?
Не по теме чата
DE
обсуждаем GDPR же
DE
ну да, должна быть возможность запросить удаление всех личных данных
репост конкретно к этому комменту
DE
короче надеюсь админы не обидятся если я кину тот классный материал в другой ипостаси: https://vc.ru/legal/53130-kiberlayfhak-besplatnaya-eda-s-pomoshchyu-gdpr
FM
вот абсолютно нет, поисковики ориентируются на ключевые слова, можно полное уг в топ вывести
Я могу ошибаться, но имею вот такое мнение:
Количество >>> качества. Это аксиома современной экономики. примеры приводить не буду.
Поэтому, если наша статья, по какой-либо тематике, топ-1 в запросе Google, то априори, она будет иметь посещаемость, допустим 50к просмотров.
Из этих 50к просмотров, 10к просмотров придется на прочтение полной статьи.
Противоположно, если статья, пусть и очень хорошая, в запросе на 500 месте. например. то кол-во уникальных просмотров, ну пусть будет 1к.
Из них статью дочитаю 100 человек.
Если ваша метрика настроена от подсчета ttr и от данного параметра считается ваш KPI, то в перовм случае вы получите премию. Даже если ваша статья ну очень плохая.
Про второй случай и так понятно в данной интерпретации.
Можно возразить, что у плохой статьи, даже на топ-1, дочитываний будет мало. Это неправлиьное возражение. И SEO вам подтвердят.
Например судя по метрикам яндексам.дзена число дочитываний (а вследствии этого денежных выплат) больше у статей не самого качественного контента, но при этом имеющих механизмы продвижения в выдаче + грамотно оформленные.
То что я описал, в заподном мире именуется болезнью - функциональной неграмотность, т.е. невозможностью человека воспринимать сложный, объемный и однотипный текст (касаемо тематики). Поэтому, современный человек при выборе материала предпочтет то что легко, что имеет оформление и что самое главное - имеет малую длину текста. А уж если этот контент выдается на первых местах запроса, допустим 1-2 страницы, то вообще замечательно. При этом, качество контента отодвигается на задний план.
Предвижу еще одно возражение, касаемо контента для профессионалов. Да, например, айтишники меньше подвержены вышеназванной болезнью. Это так и не так. Я часто встречаю статьи, и на хабре, и в иносми, о том что уровень чистоты кода каждый год снижается и современные разработчики, привыкнув к разным фреймворкам и техническим мощностям, уже не могут выдать алгоритм, потребляющий малое кол-во ресурсов и исключающий, например, большое кол-во циклов if.
При этом, я например, пишу статьи на техническую тему для одного крупного росийского ИТ-заказчика и в процессе написания статей мне приходится черпать информацию как с тематических ресурсов, так и с официальной документации. Удивлением для меня стало то кол-во технических ошибок, которое содержится в контенте (касается ру и англ. сегментов). Например, самая большая беда - это синтаксис yml файлов, который в очень большом % случае представлен в broken state. Ну или неравильные команды линукса или устаревшие проприетарные команды, которые тиражируются из дока в док, при этом сами разработчики ПО как год назад убрали эту команду.
Это подводит ко второй беде - копипаста всего и вся. Кол-во копипастенных технических статей ужасает, иностранные порталы копируют друг друга, наши порталы копируют ,переводят промтом и выкладывают, а третьи эти статьи выкладывают на свои ресурсы или берут куски и вставляют в свои доки совершенно неотдавая себе отчет, что делает этот кусок...
Впрочем ,кто дочитал сей опус? )
Сорри за ошибки. Я дико устал, а мне еще работать в ночь )
Количество >>> качества. Это аксиома современной экономики. примеры приводить не буду.
Поэтому, если наша статья, по какой-либо тематике, топ-1 в запросе Google, то априори, она будет иметь посещаемость, допустим 50к просмотров.
Из этих 50к просмотров, 10к просмотров придется на прочтение полной статьи.
Противоположно, если статья, пусть и очень хорошая, в запросе на 500 месте. например. то кол-во уникальных просмотров, ну пусть будет 1к.
Из них статью дочитаю 100 человек.
Если ваша метрика настроена от подсчета ttr и от данного параметра считается ваш KPI, то в перовм случае вы получите премию. Даже если ваша статья ну очень плохая.
Про второй случай и так понятно в данной интерпретации.
Можно возразить, что у плохой статьи, даже на топ-1, дочитываний будет мало. Это неправлиьное возражение. И SEO вам подтвердят.
Например судя по метрикам яндексам.дзена число дочитываний (а вследствии этого денежных выплат) больше у статей не самого качественного контента, но при этом имеющих механизмы продвижения в выдаче + грамотно оформленные.
То что я описал, в заподном мире именуется болезнью - функциональной неграмотность, т.е. невозможностью человека воспринимать сложный, объемный и однотипный текст (касаемо тематики). Поэтому, современный человек при выборе материала предпочтет то что легко, что имеет оформление и что самое главное - имеет малую длину текста. А уж если этот контент выдается на первых местах запроса, допустим 1-2 страницы, то вообще замечательно. При этом, качество контента отодвигается на задний план.
Предвижу еще одно возражение, касаемо контента для профессионалов. Да, например, айтишники меньше подвержены вышеназванной болезнью. Это так и не так. Я часто встречаю статьи, и на хабре, и в иносми, о том что уровень чистоты кода каждый год снижается и современные разработчики, привыкнув к разным фреймворкам и техническим мощностям, уже не могут выдать алгоритм, потребляющий малое кол-во ресурсов и исключающий, например, большое кол-во циклов if.
При этом, я например, пишу статьи на техническую тему для одного крупного росийского ИТ-заказчика и в процессе написания статей мне приходится черпать информацию как с тематических ресурсов, так и с официальной документации. Удивлением для меня стало то кол-во технических ошибок, которое содержится в контенте (касается ру и англ. сегментов). Например, самая большая беда - это синтаксис yml файлов, который в очень большом % случае представлен в broken state. Ну или неравильные команды линукса или устаревшие проприетарные команды, которые тиражируются из дока в док, при этом сами разработчики ПО как год назад убрали эту команду.
Это подводит ко второй беде - копипаста всего и вся. Кол-во копипастенных технических статей ужасает, иностранные порталы копируют друг друга, наши порталы копируют ,переводят промтом и выкладывают, а третьи эти статьи выкладывают на свои ресурсы или берут куски и вставляют в свои доки совершенно неотдавая себе отчет, что делает этот кусок...
Впрочем ,кто дочитал сей опус? )
Сорри за ошибки. Я дико устал, а мне еще работать в ночь )
DE
Fox Mulder
Я могу ошибаться, но имею вот такое мнение:
Количество >>> качества. Это аксиома современной экономики. примеры приводить не буду.
Поэтому, если наша статья, по какой-либо тематике, топ-1 в запросе Google, то априори, она будет иметь посещаемость, допустим 50к просмотров.
Из этих 50к просмотров, 10к просмотров придется на прочтение полной статьи.
Противоположно, если статья, пусть и очень хорошая, в запросе на 500 месте. например. то кол-во уникальных просмотров, ну пусть будет 1к.
Из них статью дочитаю 100 человек.
Если ваша метрика настроена от подсчета ttr и от данного параметра считается ваш KPI, то в перовм случае вы получите премию. Даже если ваша статья ну очень плохая.
Про второй случай и так понятно в данной интерпретации.
Можно возразить, что у плохой статьи, даже на топ-1, дочитываний будет мало. Это неправлиьное возражение. И SEO вам подтвердят.
Например судя по метрикам яндексам.дзена число дочитываний (а вследствии этого денежных выплат) больше у статей не самого качественного контента, но при этом имеющих механизмы продвижения в выдаче + грамотно оформленные.
То что я описал, в заподном мире именуется болезнью - функциональной неграмотность, т.е. невозможностью человека воспринимать сложный, объемный и однотипный текст (касаемо тематики). Поэтому, современный человек при выборе материала предпочтет то что легко, что имеет оформление и что самое главное - имеет малую длину текста. А уж если этот контент выдается на первых местах запроса, допустим 1-2 страницы, то вообще замечательно. При этом, качество контента отодвигается на задний план.
Предвижу еще одно возражение, касаемо контента для профессионалов. Да, например, айтишники меньше подвержены вышеназванной болезнью. Это так и не так. Я часто встречаю статьи, и на хабре, и в иносми, о том что уровень чистоты кода каждый год снижается и современные разработчики, привыкнув к разным фреймворкам и техническим мощностям, уже не могут выдать алгоритм, потребляющий малое кол-во ресурсов и исключающий, например, большое кол-во циклов if.
При этом, я например, пишу статьи на техническую тему для одного крупного росийского ИТ-заказчика и в процессе написания статей мне приходится черпать информацию как с тематических ресурсов, так и с официальной документации. Удивлением для меня стало то кол-во технических ошибок, которое содержится в контенте (касается ру и англ. сегментов). Например, самая большая беда - это синтаксис yml файлов, который в очень большом % случае представлен в broken state. Ну или неравильные команды линукса или устаревшие проприетарные команды, которые тиражируются из дока в док, при этом сами разработчики ПО как год назад убрали эту команду.
Это подводит ко второй беде - копипаста всего и вся. Кол-во копипастенных технических статей ужасает, иностранные порталы копируют друг друга, наши порталы копируют ,переводят промтом и выкладывают, а третьи эти статьи выкладывают на свои ресурсы или берут куски и вставляют в свои доки совершенно неотдавая себе отчет, что делает этот кусок...
Впрочем ,кто дочитал сей опус? )
Сорри за ошибки. Я дико устал, а мне еще работать в ночь )
Количество >>> качества. Это аксиома современной экономики. примеры приводить не буду.
Поэтому, если наша статья, по какой-либо тематике, топ-1 в запросе Google, то априори, она будет иметь посещаемость, допустим 50к просмотров.
Из этих 50к просмотров, 10к просмотров придется на прочтение полной статьи.
Противоположно, если статья, пусть и очень хорошая, в запросе на 500 месте. например. то кол-во уникальных просмотров, ну пусть будет 1к.
Из них статью дочитаю 100 человек.
Если ваша метрика настроена от подсчета ttr и от данного параметра считается ваш KPI, то в перовм случае вы получите премию. Даже если ваша статья ну очень плохая.
Про второй случай и так понятно в данной интерпретации.
Можно возразить, что у плохой статьи, даже на топ-1, дочитываний будет мало. Это неправлиьное возражение. И SEO вам подтвердят.
Например судя по метрикам яндексам.дзена число дочитываний (а вследствии этого денежных выплат) больше у статей не самого качественного контента, но при этом имеющих механизмы продвижения в выдаче + грамотно оформленные.
То что я описал, в заподном мире именуется болезнью - функциональной неграмотность, т.е. невозможностью человека воспринимать сложный, объемный и однотипный текст (касаемо тематики). Поэтому, современный человек при выборе материала предпочтет то что легко, что имеет оформление и что самое главное - имеет малую длину текста. А уж если этот контент выдается на первых местах запроса, допустим 1-2 страницы, то вообще замечательно. При этом, качество контента отодвигается на задний план.
Предвижу еще одно возражение, касаемо контента для профессионалов. Да, например, айтишники меньше подвержены вышеназванной болезнью. Это так и не так. Я часто встречаю статьи, и на хабре, и в иносми, о том что уровень чистоты кода каждый год снижается и современные разработчики, привыкнув к разным фреймворкам и техническим мощностям, уже не могут выдать алгоритм, потребляющий малое кол-во ресурсов и исключающий, например, большое кол-во циклов if.
При этом, я например, пишу статьи на техническую тему для одного крупного росийского ИТ-заказчика и в процессе написания статей мне приходится черпать информацию как с тематических ресурсов, так и с официальной документации. Удивлением для меня стало то кол-во технических ошибок, которое содержится в контенте (касается ру и англ. сегментов). Например, самая большая беда - это синтаксис yml файлов, который в очень большом % случае представлен в broken state. Ну или неравильные команды линукса или устаревшие проприетарные команды, которые тиражируются из дока в док, при этом сами разработчики ПО как год назад убрали эту команду.
Это подводит ко второй беде - копипаста всего и вся. Кол-во копипастенных технических статей ужасает, иностранные порталы копируют друг друга, наши порталы копируют ,переводят промтом и выкладывают, а третьи эти статьи выкладывают на свои ресурсы или берут куски и вставляют в свои доки совершенно неотдавая себе отчет, что делает этот кусок...
Впрочем ,кто дочитал сей опус? )
Сорри за ошибки. Я дико устал, а мне еще работать в ночь )
я дочитал и это было офигенно
DE
но одно но
DE
это все касательно текстов для интернета, а если нужно понять качество внутрикорпоративной документации
DE
поиск в конфлюэнс совсем не такой как в гугле
A
Fox Mulder
Я могу ошибаться, но имею вот такое мнение:
Количество >>> качества. Это аксиома современной экономики. примеры приводить не буду.
Поэтому, если наша статья, по какой-либо тематике, топ-1 в запросе Google, то априори, она будет иметь посещаемость, допустим 50к просмотров.
Из этих 50к просмотров, 10к просмотров придется на прочтение полной статьи.
Противоположно, если статья, пусть и очень хорошая, в запросе на 500 месте. например. то кол-во уникальных просмотров, ну пусть будет 1к.
Из них статью дочитаю 100 человек.
Если ваша метрика настроена от подсчета ttr и от данного параметра считается ваш KPI, то в перовм случае вы получите премию. Даже если ваша статья ну очень плохая.
Про второй случай и так понятно в данной интерпретации.
Можно возразить, что у плохой статьи, даже на топ-1, дочитываний будет мало. Это неправлиьное возражение. И SEO вам подтвердят.
Например судя по метрикам яндексам.дзена число дочитываний (а вследствии этого денежных выплат) больше у статей не самого качественного контента, но при этом имеющих механизмы продвижения в выдаче + грамотно оформленные.
То что я описал, в заподном мире именуется болезнью - функциональной неграмотность, т.е. невозможностью человека воспринимать сложный, объемный и однотипный текст (касаемо тематики). Поэтому, современный человек при выборе материала предпочтет то что легко, что имеет оформление и что самое главное - имеет малую длину текста. А уж если этот контент выдается на первых местах запроса, допустим 1-2 страницы, то вообще замечательно. При этом, качество контента отодвигается на задний план.
Предвижу еще одно возражение, касаемо контента для профессионалов. Да, например, айтишники меньше подвержены вышеназванной болезнью. Это так и не так. Я часто встречаю статьи, и на хабре, и в иносми, о том что уровень чистоты кода каждый год снижается и современные разработчики, привыкнув к разным фреймворкам и техническим мощностям, уже не могут выдать алгоритм, потребляющий малое кол-во ресурсов и исключающий, например, большое кол-во циклов if.
При этом, я например, пишу статьи на техническую тему для одного крупного росийского ИТ-заказчика и в процессе написания статей мне приходится черпать информацию как с тематических ресурсов, так и с официальной документации. Удивлением для меня стало то кол-во технических ошибок, которое содержится в контенте (касается ру и англ. сегментов). Например, самая большая беда - это синтаксис yml файлов, который в очень большом % случае представлен в broken state. Ну или неравильные команды линукса или устаревшие проприетарные команды, которые тиражируются из дока в док, при этом сами разработчики ПО как год назад убрали эту команду.
Это подводит ко второй беде - копипаста всего и вся. Кол-во копипастенных технических статей ужасает, иностранные порталы копируют друг друга, наши порталы копируют ,переводят промтом и выкладывают, а третьи эти статьи выкладывают на свои ресурсы или берут куски и вставляют в свои доки совершенно неотдавая себе отчет, что делает этот кусок...
Впрочем ,кто дочитал сей опус? )
Сорри за ошибки. Я дико устал, а мне еще работать в ночь )
Количество >>> качества. Это аксиома современной экономики. примеры приводить не буду.
Поэтому, если наша статья, по какой-либо тематике, топ-1 в запросе Google, то априори, она будет иметь посещаемость, допустим 50к просмотров.
Из этих 50к просмотров, 10к просмотров придется на прочтение полной статьи.
Противоположно, если статья, пусть и очень хорошая, в запросе на 500 месте. например. то кол-во уникальных просмотров, ну пусть будет 1к.
Из них статью дочитаю 100 человек.
Если ваша метрика настроена от подсчета ttr и от данного параметра считается ваш KPI, то в перовм случае вы получите премию. Даже если ваша статья ну очень плохая.
Про второй случай и так понятно в данной интерпретации.
Можно возразить, что у плохой статьи, даже на топ-1, дочитываний будет мало. Это неправлиьное возражение. И SEO вам подтвердят.
Например судя по метрикам яндексам.дзена число дочитываний (а вследствии этого денежных выплат) больше у статей не самого качественного контента, но при этом имеющих механизмы продвижения в выдаче + грамотно оформленные.
То что я описал, в заподном мире именуется болезнью - функциональной неграмотность, т.е. невозможностью человека воспринимать сложный, объемный и однотипный текст (касаемо тематики). Поэтому, современный человек при выборе материала предпочтет то что легко, что имеет оформление и что самое главное - имеет малую длину текста. А уж если этот контент выдается на первых местах запроса, допустим 1-2 страницы, то вообще замечательно. При этом, качество контента отодвигается на задний план.
Предвижу еще одно возражение, касаемо контента для профессионалов. Да, например, айтишники меньше подвержены вышеназванной болезнью. Это так и не так. Я часто встречаю статьи, и на хабре, и в иносми, о том что уровень чистоты кода каждый год снижается и современные разработчики, привыкнув к разным фреймворкам и техническим мощностям, уже не могут выдать алгоритм, потребляющий малое кол-во ресурсов и исключающий, например, большое кол-во циклов if.
При этом, я например, пишу статьи на техническую тему для одного крупного росийского ИТ-заказчика и в процессе написания статей мне приходится черпать информацию как с тематических ресурсов, так и с официальной документации. Удивлением для меня стало то кол-во технических ошибок, которое содержится в контенте (касается ру и англ. сегментов). Например, самая большая беда - это синтаксис yml файлов, который в очень большом % случае представлен в broken state. Ну или неравильные команды линукса или устаревшие проприетарные команды, которые тиражируются из дока в док, при этом сами разработчики ПО как год назад убрали эту команду.
Это подводит ко второй беде - копипаста всего и вся. Кол-во копипастенных технических статей ужасает, иностранные порталы копируют друг друга, наши порталы копируют ,переводят промтом и выкладывают, а третьи эти статьи выкладывают на свои ресурсы или берут куски и вставляют в свои доки совершенно неотдавая себе отчет, что делает этот кусок...
Впрочем ,кто дочитал сей опус? )
Сорри за ошибки. Я дико устал, а мне еще работать в ночь )
кстати, соглашусь тоже, я когда гуглю что то, то в подавляющем большинстве случаев нахожу годный контент не на 2 или 3 странице поиска, а ближе к 10 и за 10 страницей, а на первых трёх страницах делать особо нечего, сплошная тупая копипаста в разном обрамлении
DE
кстати, соглашусь тоже, я когда гуглю что то, то в подавляющем большинстве случаев нахожу годный контент не на 2 или 3 странице поиска, а ближе к 10 и за 10 страницей, а на первых трёх страницах делать особо нечего, сплошная тупая копипаста в разном обрамлении
Странный Гугл у вас ... Ну или особый метод составления поисковых запросов
FM
это все касательно текстов для интернета, а если нужно понять качество внутрикорпоративной документации
Согласен и не спорю. Если мы пишем для внутреннего юзера, то в первую очередь ориентируемся на то, какую роль занимает этот юзер: будет ли он разработчиком или оператором АРМ. Стиль, наличие проф жаргона, полнота будет меняться.
Но тут есть вот такой момент. Например. я пишу инструкцию к АРМ. Как измерить метрику оного? Ведь она она должна быть 100%, то бишь оператор АРМ обязан ознакомиться с ней и сдать некий зачет, иначе его не допустят до места.
Если эта документация для разработчиков и мы описываем какой-либо API, то метрикой что будет? Наверное тут правы ребята, которые делали доклады на эти темы.
С другой стороны, если дока для разрабов просто фигня, то они и без метрики тебе это скажут )
Мне кажется метрики более важны в B2B по полне понятным причинам.
Но тут есть вот такой момент. Например. я пишу инструкцию к АРМ. Как измерить метрику оного? Ведь она она должна быть 100%, то бишь оператор АРМ обязан ознакомиться с ней и сдать некий зачет, иначе его не допустят до места.
Если эта документация для разработчиков и мы описываем какой-либо API, то метрикой что будет? Наверное тут правы ребята, которые делали доклады на эти темы.
С другой стороны, если дока для разрабов просто фигня, то они и без метрики тебе это скажут )
Мне кажется метрики более важны в B2B по полне понятным причинам.
A
Странный Гугл у вас ... Ну или особый метод составления поисковых запросов
на первых строчках реально полезные вещи выводятся только, если гуглишь коды ошибок, команды с параметрами или ещё какие-либо специфические вещи, сразу на стаковерфлоу или проф форумы, если надо что-то теоретическое почитать, заресёрчить какую-то тему, то тут одной страницы достаточно, чтобы уловить стиль и смысл первых 5 страниц поиска, что-то полезное потом найти сложно, и я всегда дохожу до 10 и выше страницы поиска, там часто что-то уникальное и полезное есть
вот такой у меня гуглояндекс
вот такой у меня гуглояндекс
2019 August 08
FM
Пишу статью про разделение разрядов в числах. Она выйдет на следующей неделе, так как надо всё проверить на разных мониторах и операционных системах.
А пока решил с вами поделиться набором пробелов на все случаи жизни (они спрятаны между разрядами).
10 000 — обычный
10 000 — тонкий
10 000 — волос
10000 — нулевой
Неразрывные
10 000 — обычный [⌥ + пробел]
10 000 — тонкий
10000 — нулевой
Причём, нулевой пробел — это не отсутствие пробела, а прям символ. Например, они нужны для того, чтобы разбитькомбинациюсимволовдляпереносанаразныестроки. Или, наоборот склеить конструкцию так, чтобы она не переносилась +7 000-00-00
Подробная статья про пробелы: http://jkorpela.fi/chars/spaces.html
А пока решил с вами поделиться набором пробелов на все случаи жизни (они спрятаны между разрядами).
10 000 — обычный
10 000 — тонкий
10 000 — волос
10000 — нулевой
Неразрывные
10 000 — обычный [⌥ + пробел]
10 000 — тонкий
10000 — нулевой
Причём, нулевой пробел — это не отсутствие пробела, а прям символ. Например, они нужны для того, чтобы разбитькомбинациюсимволовдляпереносанаразныестроки. Или, наоборот склеить конструкцию так, чтобы она не переносилась +7 000-00-00
Подробная статья про пробелы: http://jkorpela.fi/chars/spaces.html
BG
Вот это у людей проблемы)
DE
Fox Mulder
Пишу статью про разделение разрядов в числах. Она выйдет на следующей неделе, так как надо всё проверить на разных мониторах и операционных системах.
А пока решил с вами поделиться набором пробелов на все случаи жизни (они спрятаны между разрядами).
10 000 — обычный
10 000 — тонкий
10 000 — волос
10000 — нулевой
Неразрывные
10 000 — обычный [⌥ + пробел]
10 000 — тонкий
10000 — нулевой
Причём, нулевой пробел — это не отсутствие пробела, а прям символ. Например, они нужны для того, чтобы разбитькомбинациюсимволовдляпереносанаразныестроки. Или, наоборот склеить конструкцию так, чтобы она не переносилась +7 000-00-00
Подробная статья про пробелы: http://jkorpela.fi/chars/spaces.html
А пока решил с вами поделиться набором пробелов на все случаи жизни (они спрятаны между разрядами).
10 000 — обычный
10 000 — тонкий
10 000 — волос
10000 — нулевой
Неразрывные
10 000 — обычный [⌥ + пробел]
10 000 — тонкий
10000 — нулевой
Причём, нулевой пробел — это не отсутствие пробела, а прям символ. Например, они нужны для того, чтобы разбитькомбинациюсимволовдляпереносанаразныестроки. Или, наоборот склеить конструкцию так, чтобы она не переносилась +7 000-00-00
Подробная статья про пробелы: http://jkorpela.fi/chars/spaces.html
По теме https://habr.com/ru/post/311518/
DE
еще из игрушек помню волшебный невидимый символ alt+255 (циферки вводить на числовой половинке клавы)
ИЦ
Коллеги, а есть какой-то формат, подобный markdown-у, но для нормальной работы с таблицами? Так, чтобы потом конвертировать в xlsx.
IA
Коллеги, а есть какой-то формат, подобный markdown-у, но для нормальной работы с таблицами? Так, чтобы потом конвертировать в xlsx.
asciidoc?