А вы, конечно же, занимаетесь противозаконной деятельностью или держить на гмыле бизнесовую информацию. У каждого сервиса есть своя область применения. Никто не додумается держать top secret ololo информацию на companyname@gmail.com и не станет, тем более, вести переписки об организации террористической операции.
А я вот вообще не понимаю всех этих вопросов касательно слежки за пользователями. Если я правильно понимаю, то гугл все равно обрабатывает ваши данные на уровне алгоритмов машинного обучения и никто в действительности ваши личные данные не читает, чего бояться?
По сети всегда будет полно разговоров, что %thing_name& позволяет отслеживать пользователей или делать что-либо грязнопечальнозлоплохое, это же интернет. Сорец QUIC лежит в дереве хромиума, все открыто и прозрачно. Если хочешь убедиться, что большой брат или не дай Бог, сестра, за тобой следят, можешь почитать.
Твоя мама увлекается такими штукенциями? Зачот! К слову, своей я купил понравившийся ей HTC Desire с двумя симками, а там отвратнейшая сборка андроида от HTC. Попробовал его разлочить да на свой страх и риск поставить стоковую, и ты знаешь что? Бутлоадер на корейском! WTF, подумал я и забил.
Всю статью не читал, потому что как обычно, очередная каша про то, как правильно писать SASS, но вот насчет первого примера в «Скромных примесях» выскажусь. Я считаю, что это чистейшей воды антипаттерн и правильно было бы сделать все на чистом CSS и не вы**ываться:
Почему нужно делать именно так? Это банально интуитивнее. Потом, в HTML коде вы будете писать все естественным языком, не городить забор. Взгляните на пример:
Cогласитесь, первый вариант будет лучше второго, потому что это естественный язык, естественная подача информации. По большому счету, никакого существенного отличия вроде и нет, но разметку писать стало проще понятней и мы не стали плодить сущности с этими вашими миксинами. Миксины — это хороший пример того, как народ неверно интерпритирует концепцию. Изначально они создавались, чтобы выносить какие-то квирки (хаки/костыли/whatever) в отдельные функциональные единицы кода.
Прикладные приложения — это уже совсем отдельная тема. Тем более, в контексте БАК. Там работают высококлассные специалисты одновременно по физике, информатики и куче других дисциплин. Исследования, все дела.
Какое бы это не было пользовательское приложение, бизнес-логики в нем всегда будет намного-намного больше алгоритмической части, что называется, under the hood. Даже если смотреть на Google, где огромная BigData (как я люблю этот термин) и агрессивный хайлоад.
«Олимпиадник» — впечатляюще ацтойное слово. Что значит, олимпиадник? Тот, кто в школе / университете занимался спортивным программированием на разных соревнованиях-олипиадах? Вот я сейчас учусь в 10 классе, хожу на киевские по программированию с класса седьмого-восьмого и честно признаться, не хочу, чтобы меня называли «олимпиадником», это даже звучит, как ругательство какое-то.
Реальность такова, что в проекте у тебя 90% бизнес-логики, прочей рутины и ровно 5-10% алгоритмов. Где-то надо эффективно сделать выборку, где-то надо найти максимальный поток в графе (пишем Форда-Фалкерсона). А подавляющая часть кода: тупые вьюхи и UX (в случае с пользовательскими приложениями). Есть куда более актуальные проблемы: например, работа с базами данных. У меня много знакомых программистов, уже выпускников (sic!) киевских университетов, которые просто не включают мозг при работе с БД.
Software Engineer не должен быть переученым олимпиадником и не должен быть code monkey, который не слышал о MapReduce. Инженер должен правильно решать поставленные перед ним технические задачи, по возможности, максимально эффективным образом. Спортивное программирование, же, в свою очередь, это хобби. Реального применения у него попросту нет, ведь необходимый набор из пятидесяти с копейками алгоритмов можно освоить не решая задачки с топкодера.
Кхек, это уже дело личного человека. Мне, например, откровенно насрать, анализируют ли они мои письма или нет. Скорее всего это работает по принципу big data, тоесть к информации в том понимании, в котором вы ее понимаете для себя, они не имеют никакого интереса.
Не знаю, как с SASS, но LESS позволяет просто сделать так (и я считаю, что это элегантно):
Почему нужно делать именно так? Это банально интуитивнее. Потом, в HTML коде вы будете писать все естественным языком, не городить забор. Взгляните на пример:
Cогласитесь, первый вариант будет лучше второго, потому что это естественный язык, естественная подача информации. По большому счету, никакого существенного отличия вроде и нет, но разметку писать стало проще понятней и мы не стали плодить сущности с этими вашими миксинами. Миксины — это хороший пример того, как народ неверно интерпритирует концепцию. Изначально они создавались, чтобы выносить какие-то квирки (хаки/костыли/whatever) в отдельные функциональные единицы кода.
Будто что-то плохое!
Реальность такова, что в проекте у тебя 90% бизнес-логики, прочей рутины и ровно 5-10% алгоритмов. Где-то надо эффективно сделать выборку, где-то надо найти максимальный поток в графе (пишем Форда-Фалкерсона). А подавляющая часть кода: тупые вьюхи и UX (в случае с пользовательскими приложениями). Есть куда более актуальные проблемы: например, работа с базами данных. У меня много знакомых программистов, уже выпускников (sic!) киевских университетов, которые просто не включают мозг при работе с БД.
Software Engineer не должен быть переученым олимпиадником и не должен быть code monkey, который не слышал о MapReduce. Инженер должен правильно решать поставленные перед ним технические задачи, по возможности, максимально эффективным образом. Спортивное программирование, же, в свою очередь, это хобби. Реального применения у него попросту нет, ведь необходимый набор из пятидесяти с копейками алгоритмов можно освоить не решая задачки с топкодера.