А что, если создать два раздела? Приглашения и запросы. Пусть запросы и будут работать с эффективностью, близкой к нулевой, но станет очевидно что к чему. Потом можно будет подумать и над повышением КПД раздела.
При создании же поста с раздачей приглашений можно выделить два поля. «У меня есть приглашения на» и описание.
Думаю, к чему-то похожему универсальному приходит чуть ли не каждый разработчик. Потом это решение переходит из проекта в проект, потихоньку совершенствуясь.
Заглядывая под кат, ожидал увидеть jQuery плагин. Или вы по каким-то причинам не пользуетесь сторонними библиотеками?
Так не только ж зарплатные же. «Хочу работать на себя», «Фейсбук не так уж и плох», «Да пошло оно всё, я в Бразилии». Даже в статье в качестве примера приведены ребята, которые ушли из Гугла.
Таки, мне кажется, что и ответ с производными неправильный.
Нельзя игнорировать и то обстоятельство, что ожидания (зарплатные и прочие) работника, вероятно, будут коррелировать с этими графиками. И становится весьма важно, а как долго вы этого человека сможете удержать. Так что важны отнюдь не производные, а интегралы — площади под кривыми.
Мне понравилось, но «программность» видна невооружённым взглядом. Шарма это обстоятельство не добавляет.
Чтобы сделать эффект качественно, нужна как минимум карта расстояний. Объекты в плоскости фокусировки не размываются, чем дальше от этой плоскости, тем сильнее размытие. Это либо достаточно кропотливая ручная работа в фотошопе, либо весьма и весьма умный алгоритм, умеющий считать расстояния по одной фоторгафии.
Не знаю, насколько предложения ниже можно считать улучшениями, но
1. Я не включал бы выходные в выборку. (см комментарий выше).
2. Оперировал бы не размахом, а среднеквадратическим отклонением.
3. Для каждой группы доверительный интервал считал бы отдельно. Плюс-минус три сигма, например.
Что бы это дало? Например, если бы в понедельник на протяжении 10 недель я выполнял ровно по 10 задач, а в среднем за день — 9, то это позволило бы выделить понедельник. А если бы в понедельник выполнялось от 8 до 12 задач (в среднем по понедельникам — 10) при том же среднем 9 за все дни, то понедельник был бы обычным днём.
Отвлекаются — потому что интересно. Так зачем же их в этом ограничивать? Как по мне, смысл же не в самой игре, а в том, чтоб понять как оно всё устроено и как работает.
В свои 7 лет, чтобы поиграть на Спектруме в змейку, я сам её набирал из книжки по бейсику. И так каждый раз — сохранить было некуда. Что в этом плохого (во вполне взрослом бейсике)? Да как по мне, ничего совершенно. Только через несколько месяцев мне купили пару кассет с играми, и всё свелось к лоад-двекавычки-ентер.
Хотя, впрочем, «зкранные интерфейсы для детей от двух до пяти» — весьма специфичная тема. И что-то сколь-нибудь авторитетно заявлять я ни в коем случае не могу.
У меня немного другие соображения. Я убеждён, что определение корректности состояния объекта должно лежать на нём самом. И интерфейс не должен позволять привести объект в некорректное состояние. И, в том числе и это, — именно то, зачем нужна инкапсуляция. Если же и связи, и углы являются свойствами атома и выставляются извне, то получить такое состояние запросто.
Если же взаимосвязь атомов — это свойство молекулы, её можно спроектировать так, что её состояние будет всегда корректно.
К свойствам атома я отнёс бы только атомную массу, валентность, порядковый номер в таблице Менделеева и радиус. Может быть, не всё важное назвал или что-то упустил, не суть. Связи атомов — это уже свойство класса РНК. Как их задавать — множеством рёбер, матрицей смежности или матрицей инцидентности — решаем из соображений удобства, располагаемой памяти и т.д. Тогда получается, что углы — просто отношения между смежными рёбрами. Но — множество углов является характеристикой РНК, но не атома и не связи. И именно класс РНК должен следить за непротиворечивостью углов и связей.
Совершенно не утверждаю, что подобная декомпозиция удобнее в обработке, выигрышнее по памяти, производительности или что-то в таком духе. Просто мне кажется, что именно что-то такое вы имели ввиду во втором своём варианте. И, как по мне, это самое что ни на есть ООП.
А мне почему-то кажется, что второй вариант — и есть правильная декомпозиция предметной области. Потому как такая совокупность свойств связанных объектов — это характеристика связующего их графа, но не их самих.
На примере. Есть несколько лампочек и несколько батареек. Свойства лампочек — номинальное напряжение и номинальная мощность. Свойства батареек — внутреннее сопротивление и ЭДС. Реальная же мощность каждой такой лампочки зависит от схемы включения всего этого добра, и характеризует не столько лампочку, сколько схему.
При создании же поста с раздачей приглашений можно выделить два поля. «У меня есть приглашения на» и описание.
Заглядывая под кат, ожидал увидеть jQuery плагин. Или вы по каким-то причинам не пользуетесь сторонними библиотеками?
Нельзя игнорировать и то обстоятельство, что ожидания (зарплатные и прочие) работника, вероятно, будут коррелировать с этими графиками. И становится весьма важно, а как долго вы этого человека сможете удержать. Так что важны отнюдь не производные, а интегралы — площади под кривыми.
Чтобы сделать эффект качественно, нужна как минимум карта расстояний. Объекты в плоскости фокусировки не размываются, чем дальше от этой плоскости, тем сильнее размытие. Это либо достаточно кропотливая ручная работа в фотошопе, либо весьма и весьма умный алгоритм, умеющий считать расстояния по одной фоторгафии.
Что касается алгоритма, то как минимум нужно использовать что-то похожее habrahabr.ru/post/95541/.
1. Я не включал бы выходные в выборку. (см комментарий выше).
2. Оперировал бы не размахом, а среднеквадратическим отклонением.
3. Для каждой группы доверительный интервал считал бы отдельно. Плюс-минус три сигма, например.
Что бы это дало? Например, если бы в понедельник на протяжении 10 недель я выполнял ровно по 10 задач, а в среднем за день — 9, то это позволило бы выделить понедельник. А если бы в понедельник выполнялось от 8 до 12 задач (в среднем по понедельникам — 10) при том же среднем 9 за все дни, то понедельник был бы обычным днём.
В свои 7 лет, чтобы поиграть на Спектруме в змейку, я сам её набирал из книжки по бейсику. И так каждый раз — сохранить было некуда. Что в этом плохого (во вполне взрослом бейсике)? Да как по мне, ничего совершенно. Только через несколько месяцев мне купили пару кассет с играми, и всё свелось к лоад-двекавычки-ентер.
Хотя, впрочем, «зкранные интерфейсы для детей от двух до пяти» — весьма специфичная тема. И что-то сколь-нибудь авторитетно заявлять я ни в коем случае не могу.
Не такие уж дети и глупые, чтобы меню от них скрывать.
Если же взаимосвязь атомов — это свойство молекулы, её можно спроектировать так, что её состояние будет всегда корректно.
Совершенно не утверждаю, что подобная декомпозиция удобнее в обработке, выигрышнее по памяти, производительности или что-то в таком духе. Просто мне кажется, что именно что-то такое вы имели ввиду во втором своём варианте. И, как по мне, это самое что ни на есть ООП.
На примере. Есть несколько лампочек и несколько батареек. Свойства лампочек — номинальное напряжение и номинальная мощность. Свойства батареек — внутреннее сопротивление и ЭДС. Реальная же мощность каждой такой лампочки зависит от схемы включения всего этого добра, и характеризует не столько лампочку, сколько схему.