Не вполне уверен, что такое UX-мероприятие. Решил обратиться к первоисточнику:
Там явно фигурирует быстродействие, во втором абзаце. Если расмотреть пятиуровневую модель, то быстродействие относится к пятому уровню — "желания и ожидания" от продукта.
Я вот понимаю под UX user experience — т.е. впечатление пользователя от сайта. А скорость загрузки и работы сайта — один из важнейших показателей удовлетворенности пользователей.
У динамической линковки есть только один большой плюс — это экономия оперативной памяти, т.к. внешняя библиотека грузится один раз и затем маппится в каждый процесс. Ну и экономия диска, да. Но актуальном все это становится на современном железе, только если таких скомпилированных приложений и процессов — десятки.
А если делать выбор между "скопируй бинарник на другую машину и он заработает" и "без установленных библиотек правильной версии не запустится"...
В 90е в хороших школах на информатике детям давали два языка — сначала бейсик, потом паскаль. Сейчас, имхо, питон прочно занимает нишу бейсика. Но если ограничиваться только питоном, то на выходе получаются чистые прикладники. И мы видем тонны ужасных библиотек на питоне, статьи "питон как крутой язык для data science" и программистов, не знающих шестнадцатеричные системы счисления.
Имхо, хорошим стартом является питон (5-8 класс) + С (9-11). Паскаль хоть и по-прежнему хорош для обучения базовым алгоритмам и структурам данных, но очень уж устарел как язык.
(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. "нетворкинг" и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.
В целом, важно понимать, что одна из крупнейших проблем в больших компаниях — это проблема коммуникации. Нехватка знаний инфраструктуры, бизнес-процессов, потребностей других отделов и команд приводит к тому, что значительная часть труда тратится или вхолостую, или на провторную прокладку путей, уже пройденных другими.
Вот про пассивное исполнительство хорошо сказано. Иметь собственный стиль могут себе позволить всякие-разные начальники по дизайну и свободные художники, а работать-то кто будет?
Клиентам нужно что-то либо в их корпоративном стиле, либо в стиле, который они считают наиболее подходящим для своей ЦА. А если в компании больше одного дизайнера, то большинство должны рисовать то, что им скажут.
Можно было не приводить примеры. Почти любой пользователь Интернета со стажем влегкую накидает эссе на 200 слов "почему я ненавижу mail.ru". И дизайн на пару с юзабилити займут там достойное место.
Лучше задать уважаемой аудитории другой вопрос — кто использует какой-то сервис mail.ru и не имеет претензий к его дизайну?
Быть может, это и к лучшему. JavaEE так и не смог превратиться из "стандарты ради стандартов" в современный модульный фреймворк. Эволюция повторно используемого ПО неудержимо движется в направлении от готовых платформ, которые все сделают за вас, к небольшим библиотекам, идеально выполняющим ровно одну задачу, и технологиям их композиции.
Сначала JavaEE, потом Spring XML, теперь Guice и Sping java config. сервера приложений и мегафреймворки закономерно остаются на обочине.
Интересно. Как вы считаете, как соотносятся UX-исследования с аналитикой по метрикам взаимодействия живых пользователей с интерфейсом? Не проще ли выкатить бету в публичный доступ, а потом проанализировать действия пользователей, типичные ошибки, популярность фич, повторяющиеся действия и т.п.?
Имхо, слишком сложно для использования на практике.
Начиная с первого же куска кода, зачем использовать for-yield, если можно намного проще?
def getByPath(path: List[String], root: XmlNode): Option[XmlNode] = path match {
case name::names =>
root.child.find(_.label == name).flatMap { child =>
getByPath(names, child)
}
case _ => Some(root)
}
Или еще понятнее:
def getByPath2(path: List[String], root: XmlNode): Option[XmlNode] = path match {
case name::names =>
root.child.find(_.label == name) match {
case Some(child) => getByPath(names, child)
case None => None
}
case _ => Some(root)
}
Объем кода такой же, а понять его не в пример проще. Возвращать сообщение об ошибке — так оно уже возвращается, если None — то данные не найдены. Обернуть Option в любой другой тип в отдельной функции и всё.
Что касается обобщенного кода: Scala-компактный язык. В большинстве случаев лучше написать рядышком еще одну реализацию в несколько строк, что будет и проще, и, как правило, быстрее исполняться.
Проблема Scala в том, что он, по сути, содержит в себе два языка программирования — качественный промышленный и обширный экспериментальный. Множество попыток внедрения скалы провалилось из-за того, что первые энтузиасты тщательно зашифровывали исходники библиотеками типа scalaz, превращая текст в подобие двоичного дампа. В этом плане полезно изучить опыт Twitter, а также их исходники.
Тоже в свое время пытался разобраться, как генерить пароли к RRR. Но не осилил по малолетству.
Очень интересная схема паролей в ecco the dolphin на сеге. Если взять сначала нечетные буквы, а потом четные, то часто получается рабочий пароль от другого уровня. Но рабочего генератора паролей, насколько я знаю, нет.
Ну что я могу сказать… то, что смешанные коллективы здоровее чисто мужских — это факт. Что девушки старательнее из-за страха… тот факт, что в универе полный конспект лекций проще всего найти у девушки вы тоже будете объяснять страхом? Про "стеклянный потолок" — неправда, видел я и женщин-больших начальников. Другой вопрос, что для таких должностей нужна определенная жесткость и умение принимать трудные решения, что я лично чаще видел у мужчин.
По второму абзацу — нет, не выходит. Пожалуйста, перечитайте мой предыдущий коммент внимательней. Быть может, тогда вы увидите слова "чаще встречаются нужные навыки". Обязательные навыки для такой должности.
Я думаю, что я изложил свою точку зрения и развивать полемику на тему что кому-то там недодали прав или обязанностей не намерен.
Никогда не встречался с дискриминацией женщин в IT. Скорее наборот — при равных технических знаниях и умениях девушки старательнее, девушки украшают собой офис и т.п.) Девушки часто занимают должность начальников среднего звена, т.к. у них чаще встречаются нужные для этой должности навыки — социальный интеллект, работоспособность, аккуратность, самоконтроль.
Другой вопрос, что женщин-технарей, женщин-программистов, женщин-математиков просто меньше. Ну не интересно им это в большинстве своем, то ли генетически, то ли из-за воспитания.
Для меня все эти гендерные квоты и разговоры о дискриминации — просто еще один повод оставаться работать в России.
Не вполне уверен, что такое UX-мероприятие. Решил обратиться к первоисточнику:
Там явно фигурирует быстродействие, во втором абзаце. Если расмотреть пятиуровневую модель, то быстродействие относится к пятому уровню — "желания и ожидания" от продукта.
Я вот понимаю под UX user experience — т.е. впечатление пользователя от сайта. А скорость загрузки и работы сайта — один из важнейших показателей удовлетворенности пользователей.
А по-моему, очень интересно. Надо купить большой календарь на стену)
Поисковый спам он и есть поисковый спам.
https://tools.ietf.org/html/rfc1510
Они это что, специально?
У динамической линковки есть только один большой плюс — это экономия оперативной памяти, т.к. внешняя библиотека грузится один раз и затем маппится в каждый процесс. Ну и экономия диска, да. Но актуальном все это становится на современном железе, только если таких скомпилированных приложений и процессов — десятки.
А если делать выбор между "скопируй бинарник на другую машину и он заработает" и "без установленных библиотек правильной версии не запустится"...
В 90е в хороших школах на информатике детям давали два языка — сначала бейсик, потом паскаль. Сейчас, имхо, питон прочно занимает нишу бейсика. Но если ограничиваться только питоном, то на выходе получаются чистые прикладники. И мы видем тонны ужасных библиотек на питоне, статьи "питон как крутой язык для data science" и программистов, не знающих шестнадцатеричные системы счисления.
Имхо, хорошим стартом является питон (5-8 класс) + С (9-11). Паскаль хоть и по-прежнему хорош для обучения базовым алгоритмам и структурам данных, но очень уж устарел как язык.
STL и Boost — это сплошняком извращенства с шаблонами. А человек, который считает, что он знает С++, должен хотя бы уметь понять исходники.
Три года практики? Если кто-то говорит вам, что он знает С++ и у него нет очков и бороды, то он либо врет, либо просто не читал Александреску.
Восьмой совет должен быть нулевым. Итак:
(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. "нетворкинг" и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.
В целом, важно понимать, что одна из крупнейших проблем в больших компаниях — это проблема коммуникации. Нехватка знаний инфраструктуры, бизнес-процессов, потребностей других отделов и команд приводит к тому, что значительная часть труда тратится или вхолостую, или на провторную прокладку путей, уже пройденных другими.
Судя по тексту, это скорее "мнение анонимного источника". Ну что же, ждем сенября. Очень интересно, что они придумают.
Вот про пассивное исполнительство хорошо сказано. Иметь собственный стиль могут себе позволить всякие-разные начальники по дизайну и свободные художники, а работать-то кто будет?
Клиентам нужно что-то либо в их корпоративном стиле, либо в стиле, который они считают наиболее подходящим для своей ЦА. А если в компании больше одного дизайнера, то большинство должны рисовать то, что им скажут.
Можно было не приводить примеры. Почти любой пользователь Интернета со стажем влегкую накидает эссе на 200 слов "почему я ненавижу mail.ru". И дизайн на пару с юзабилити займут там достойное место.
Лучше задать уважаемой аудитории другой вопрос — кто использует какой-то сервис mail.ru и не имеет претензий к его дизайну?
Быть может, это и к лучшему. JavaEE так и не смог превратиться из "стандарты ради стандартов" в современный модульный фреймворк. Эволюция повторно используемого ПО неудержимо движется в направлении от готовых платформ, которые все сделают за вас, к небольшим библиотекам, идеально выполняющим ровно одну задачу, и технологиям их композиции.
Сначала JavaEE, потом Spring XML, теперь Guice и Sping java config. сервера приложений и мегафреймворки закономерно остаются на обочине.
Интересно. Как вы считаете, как соотносятся UX-исследования с аналитикой по метрикам взаимодействия живых пользователей с интерфейсом? Не проще ли выкатить бету в публичный доступ, а потом проанализировать действия пользователей, типичные ошибки, популярность фич, повторяющиеся действия и т.п.?
Имхо, слишком сложно для использования на практике.
Начиная с первого же куска кода, зачем использовать for-yield, если можно намного проще?
Или еще понятнее:
Объем кода такой же, а понять его не в пример проще. Возвращать сообщение об ошибке — так оно уже возвращается, если None — то данные не найдены. Обернуть Option в любой другой тип в отдельной функции и всё.
Что касается обобщенного кода: Scala-компактный язык. В большинстве случаев лучше написать рядышком еще одну реализацию в несколько строк, что будет и проще, и, как правило, быстрее исполняться.
Проблема Scala в том, что он, по сути, содержит в себе два языка программирования — качественный промышленный и обширный экспериментальный. Множество попыток внедрения скалы провалилось из-за того, что первые энтузиасты тщательно зашифровывали исходники библиотеками типа scalaz, превращая текст в подобие двоичного дампа. В этом плане полезно изучить опыт Twitter, а также их исходники.
Тоже в свое время пытался разобраться, как генерить пароли к RRR. Но не осилил по малолетству.
Очень интересная схема паролей в ecco the dolphin на сеге. Если взять сначала нечетные буквы, а потом четные, то часто получается рабочий пароль от другого уровня. Но рабочего генератора паролей, насколько я знаю, нет.
Ну что я могу сказать… то, что смешанные коллективы здоровее чисто мужских — это факт. Что девушки старательнее из-за страха… тот факт, что в универе полный конспект лекций проще всего найти у девушки вы тоже будете объяснять страхом? Про "стеклянный потолок" — неправда, видел я и женщин-больших начальников. Другой вопрос, что для таких должностей нужна определенная жесткость и умение принимать трудные решения, что я лично чаще видел у мужчин.
По второму абзацу — нет, не выходит. Пожалуйста, перечитайте мой предыдущий коммент внимательней. Быть может, тогда вы увидите слова "чаще встречаются нужные навыки". Обязательные навыки для такой должности.
Я думаю, что я изложил свою точку зрения и развивать полемику на тему что кому-то там недодали прав или обязанностей не намерен.
Никогда не встречался с дискриминацией женщин в IT. Скорее наборот — при равных технических знаниях и умениях девушки старательнее, девушки украшают собой офис и т.п.) Девушки часто занимают должность начальников среднего звена, т.к. у них чаще встречаются нужные для этой должности навыки — социальный интеллект, работоспособность, аккуратность, самоконтроль.
Другой вопрос, что женщин-технарей, женщин-программистов, женщин-математиков просто меньше. Ну не интересно им это в большинстве своем, то ли генетически, то ли из-за воспитания.
Для меня все эти гендерные квоты и разговоры о дискриминации — просто еще один повод оставаться работать в России.