Я вам сейчас страшную тайну открою, проблема в том, что если UX зависит от кого-нибудь в команде и только от него, то всё пропало.
UX в первую очередь зависит от пользователей, часто вам не надо ничего угадывать, просто покажите ваш софт пользователям, они вам быстро сообщат, что в нём не так. И не так важно, кто будет вносить изменения, UX-люди или разработчики.
А самое смешное, что все вот эти презираемые скрамы строятся как раз вокруг этого факта: никто не знает, что нужно пользователю лучше самого пользователя, дак давайте построим процесс разработки так, чтобы как можно чаще узнавать у него, нравится ему или нет.
Сам по себе код никому не нужен, нужно средство для решения проблем. Если ваш код не такое средство, то добавленная стоимость вашей работы равна нулю.
А значит всё было зря.
Я веду к тому, что разработчики не должны думать о пользователях как о криворуких дебилах, которые не умеют пользоваться их блестяще написанным софтом. Всё наоборот, когда разработчик видит, что пользователь не может решить свои проблемы используя его код, он должен понять, что криворукий дебил тут он.
Это называется «критикал UX баг», а не кривые руки пользователя.
Разработчики очень легко забывают, что они делают продукт, а не код. Если вашим продуктом не может пользоваться пользователь, ты вы ничего не произвели, какой бы прекрасный и изящный код там ни крутился.
Если в двух словах: у человека есть две «системы чтения», одна из них работает, когда читать трудно, вторая используется для «нормального чтения». Есть основания полагать, что когда читать трудно, качество чтения выше, допускается меньше ошибок и всё такое.
Через некоторое время, правда, мозг прекрасно учится читать код без подсветки и эффект улетучивается. Так что сейчас я уже не заморачиваюсь: есть подсветка — пусть будет, нет её — не стану включать.
Эксперимент был очень полезным.
Что касается этого вот исследования: очень маленькая выборка, я думал намного больше будет. По такой выборке делать выводы нельзя, это очевидно. Вдобавок, большинство людей программируют с подсветкой синтаксиса, а значит их мозг уже натренирован на восприятие «подсвеченного текста». Само собой им проще будет с подсветкой, чем без неё.
В выводах, опять же, фигурирует слово «скорость», а вот о серьёзном контроле качества понимания прочитанного кода на такой выборке и таких примерах говорить рано.
1. В коробке есть всё, от BSD сокетов до http
2. Отлично, нативные треды, грин-треды, транзакционная память, всё есть
3. Можно, например xmonad.org
4. Честно говоря не знаю насколько удобно, но можно :)
Мне трудно сразу въехать, что делает эта софтина, очень специфичная область, в которой я ни в зуб ногой.
Но хаскель — тьюринг полный язык, так что можно точно. Производительность тоже вопрос очень спорный.
Хорошо написанная программа на Си по определению будет быстрее хорошо написанной программы на хаскеле, просто потому что в хаскеле сборка мусора и жирный рантайм.
Но, я надеюсь, мы не пытаемся сейчас обсуждать экстремумы типа «ничего на хаскеле!» и «всё на хаскеле!». Трудозатраты для написания стабильных, развесистых систем на языке с системой вывода типов а-la Хиндли-Милнер, паттерн матчингом и всякими прочими плюшками сильно меньше, чем создание такой же на Си. Поэтому нужно выбирать в каждом конкретном случае оптимальный вариант. Я бы не стал писать веб-сервис на си и драйвер файловой системы на хаскеле.
Я на нём пишу генераторы кода, а ещё он мне очень помог сесть и поехать на Scala и Swift. Хаскель ценен не сам по себе, а как источник идей из параллельного мира, который проникает в обычный довольно быстро.
В общем, хаскель нужно учить, что б можно было взять любой хайповый язык из интернета и за неделю начать на нём писать код, потому что ты уже знаешь, что такое типы высших порядков, монады, паттерн матчинг и всё вот это вот.
Ну сказанное совсем не означает, что его вот прямо нельзя использовать в продакшене.
Прямо сейчас Эр-Телеком в Перми: take.ms/YkiRS
Судя по всему они пытаются дать возможность таки ходить на гитхаб при помощи MITM атаки.
Я считаю эта ситуация просто прекрасна по всем осям.
Я не настоящий сварщик, надо сказать. К графике отношения не имею совершенно никакого, зато с 2009 года пишу под мобильники и мне кажется, вы игнорируете неприлично торчащий факт, что это библиотека для мобильных устройств.
Навскидку: OpenGL ES ≠ OpenGL. Более того, на разных операционных системах версии OpenGL ES могут оказаться неожиданно разными.
Даже если игнорировать эту неприятность, вы ведь знаете, что мобильные устройства это сложная среда? Например если вы пишете Android приложение, вам надо бриджить все вызовы к нативному коду через JNI? То есть чтобы отключить системное сглаживание надо сходить в JVM и вернуться обратно. На iOS ситуация другая, там всё проще немного, но судя по комментариям пацаны активно пилят поддержку как минимум Android, то есть таки да — отключается долго и по-разному на разных платформах почти наверняка. Я представления не имею, как это делается на Linux, Windows, Blackberry 10, Bada и прочих странных штуках, подозреваю что везде есть свои странности. Особенно учитывая, что гугление на тему разрядности буфера глубины на первой же странице выдаёт некий пост с таким приветствием:
Well, welcome to OpenGL world. :)
I hope you will survive extension hell. :)
По поводу снижения производительности я вообще не понял, даже если я, далёкий от графики вижу, что 60 fps это больше, чем 14 fps.
А если в целом, вы с лёгкостью можете поставить тут всех на место, просто рассказав, а как же надо всё это делать с примерами не для GL3.3, а для OpenGL ES, iOS и Android. Причём очень желательно для OpenGL ES 2.0 и 3.0. И чтоб портабельно. Что-то мне подсказывает, что уважаемый топикстартер всё же не в первый раз видит матчасть.
Вы знаете как дать в пах производительности (1000 треугольников, MSAA даёт 14 fps, наш — 6 fps), но при этом кичитесь тем, что вам так важна эта производительность.
Вы правда не понимаете, что 6 fps это статическая сцена? Будь там хоть 1 fps, разницы никакой, это картинка. В момент, когда пользователь пальцем начинает неистово вращать что-то, их сглаживание быстро отключается и получается 60 fps в динамике?
Я тут пытался вспомнить и углубить свой цацкель, начал читать эту книгу, но бросил, когда там сразу после очевидных примеров начался ад с теорией категорий. В качестве первой книги точно нет.
Я раскачался перечитав LYAH, но после него имеет смысл читать сразу RWH. В общем это труд достойный уважения, безусловно, но рекомендовать эту книгу я бы не рискнул.
UX в первую очередь зависит от пользователей, часто вам не надо ничего угадывать, просто покажите ваш софт пользователям, они вам быстро сообщат, что в нём не так. И не так важно, кто будет вносить изменения, UX-люди или разработчики.
А самое смешное, что все вот эти презираемые скрамы строятся как раз вокруг этого факта: никто не знает, что нужно пользователю лучше самого пользователя, дак давайте построим процесс разработки так, чтобы как можно чаще узнавать у него, нравится ему или нет.
А значит всё было зря.
Я веду к тому, что разработчики не должны думать о пользователях как о криворуких дебилах, которые не умеют пользоваться их блестяще написанным софтом. Всё наоборот, когда разработчик видит, что пользователь не может решить свои проблемы используя его код, он должен понять, что криворукий дебил тут он.
Это называется «критикал UX баг», а не кривые руки пользователя.
Разработчики очень легко забывают, что они делают продукт, а не код. Если вашим продуктом не может пользоваться пользователь, ты вы ничего не произвели, какой бы прекрасный и изящный код там ни крутился.
Выключил я её сознательно именно для того, чтобы улучшить качество кода, после встречи с замечательным человеком и прочтения вот этой статьи: www.unicog.org/publications/ReadingDegradedWordsDorsalVentral_Neuroimage2008.pdf
Если в двух словах: у человека есть две «системы чтения», одна из них работает, когда читать трудно, вторая используется для «нормального чтения». Есть основания полагать, что когда читать трудно, качество чтения выше, допускается меньше ошибок и всё такое.
Через некоторое время, правда, мозг прекрасно учится читать код без подсветки и эффект улетучивается. Так что сейчас я уже не заморачиваюсь: есть подсветка — пусть будет, нет её — не стану включать.
Эксперимент был очень полезным.
Что касается этого вот исследования: очень маленькая выборка, я думал намного больше будет. По такой выборке делать выводы нельзя, это очевидно. Вдобавок, большинство людей программируют с подсветкой синтаксиса, а значит их мозг уже натренирован на восприятие «подсвеченного текста». Само собой им проще будет с подсветкой, чем без неё.
В выводах, опять же, фигурирует слово «скорость», а вот о серьёзном контроле качества понимания прочитанного кода на такой выборке и таких примерах говорить рано.
Пока получается как на этой картинке:
1. В коробке есть всё, от BSD сокетов до http
2. Отлично, нативные треды, грин-треды, транзакционная память, всё есть
3. Можно, например xmonad.org
4. Честно говоря не знаю насколько удобно, но можно :)
Но хаскель — тьюринг полный язык, так что можно точно. Производительность тоже вопрос очень спорный.
Хорошо написанная программа на Си по определению будет быстрее хорошо написанной программы на хаскеле, просто потому что в хаскеле сборка мусора и жирный рантайм.
Но, я надеюсь, мы не пытаемся сейчас обсуждать экстремумы типа «ничего на хаскеле!» и «всё на хаскеле!». Трудозатраты для написания стабильных, развесистых систем на языке с системой вывода типов а-la Хиндли-Милнер, паттерн матчингом и всякими прочими плюшками сильно меньше, чем создание такой же на Си. Поэтому нужно выбирать в каждом конкретном случае оптимальный вариант. Я бы не стал писать веб-сервис на си и драйвер файловой системы на хаскеле.
В общем, хаскель нужно учить, что б можно было взять любой хайповый язык из интернета и за неделю начать на нём писать код, потому что ты уже знаешь, что такое типы высших порядков, монады, паттерн матчинг и всё вот это вот.
Ну сказанное совсем не означает, что его вот прямо нельзя использовать в продакшене.
На самом деле, возможно, наши админы просто умнички и сделали роут на гитхаб через более вменяемые места.
Надо спросить будет.
Который работает через гитхаб.
Судя по всему они пытаются дать возможность таки ходить на гитхаб при помощи MITM атаки.
Я считаю эта ситуация просто прекрасна по всем осям.
Навскидку: OpenGL ES ≠ OpenGL. Более того, на разных операционных системах версии OpenGL ES могут оказаться неожиданно разными.
Даже если игнорировать эту неприятность, вы ведь знаете, что мобильные устройства это сложная среда? Например если вы пишете Android приложение, вам надо бриджить все вызовы к нативному коду через JNI? То есть чтобы отключить системное сглаживание надо сходить в JVM и вернуться обратно. На iOS ситуация другая, там всё проще немного, но судя по комментариям пацаны активно пилят поддержку как минимум Android, то есть таки да — отключается долго и по-разному на разных платформах почти наверняка. Я представления не имею, как это делается на Linux, Windows, Blackberry 10, Bada и прочих странных штуках, подозреваю что везде есть свои странности. Особенно учитывая, что гугление на тему разрядности буфера глубины на первой же странице выдаёт некий пост с таким приветствием:
По поводу снижения производительности я вообще не понял, даже если я, далёкий от графики вижу, что 60 fps это больше, чем 14 fps.
А если в целом, вы с лёгкостью можете поставить тут всех на место, просто рассказав, а как же надо всё это делать с примерами не для GL3.3, а для OpenGL ES, iOS и Android. Причём очень желательно для OpenGL ES 2.0 и 3.0. И чтоб портабельно. Что-то мне подсказывает, что уважаемый топикстартер всё же не в первый раз видит матчасть.
Вы правда не понимаете, что 6 fps это статическая сцена? Будь там хоть 1 fps, разницы никакой, это картинка. В момент, когда пользователь пальцем начинает неистово вращать что-то, их сглаживание быстро отключается и получается 60 fps в динамике?
А если нужно быстро получить денег, надо просто достать их из тумбочки!
Я раскачался перечитав LYAH, но после него имеет смысл читать сразу RWH. В общем это труд достойный уважения, безусловно, но рекомендовать эту книгу я бы не рискнул.