У меня знакомые не оценили такой улей. Один сказал, что в Австралии наверное ос нет, плюс 36 тысяч рублей за один улей — это (мягко говоря) очень много, плюс по виду сбоку нельзя оценить полная рамка или нет, плюс нельзя понять, а нет ли там в рамке в данный момент приплода, плюс заменить полную рамку на новую — гораздо быстрее, чем 20 минут. Второй даже читать не стал после того, как услышал про пластиковые ячейки.
Просто, возможно, есть смысл не использовать в названиях глаголы, описанные в разделе 9 описания протокола HTTP 1.1 (который сейчас считается стандартом). Возможно, есть смысл не использовать глаголы, которые можно легко привести к какому-то глаголу из списка в 9-м разделе. Но это не повод отказываться от глаголов вообще.
У вас в вашем вопросе на Тостере просто есть ошибки — системные ошибки. Чтобы построить хороший интерфейс, нужно хорошо описать предметную область. Хорошее понимание предметной области очень сильно поможет в реализации всей архитектуры. С точки зрения ракеты, её нельзя запустить по стране или продать в страну.
Верховного Главнокомандующего Страны-Р можно заставить через REST бабахнуть по Стране-А. Это его ответственность и именно он может принимать такие решения, так как является в этой ситуации ключевым ресурсом. Перед тем, как ракета прилетит в Страну-А, произойдёт ещё куча REST-вызовов к различным ресурсам. Один ресурс содержит коллекцию координат, по которым эффективнее всего долбить в конкретной стране. Второй ресурс содержит коллекцию ракет, которые наиболее эффективным образом смогут пролететь от точки с текущими координатами до цели с какими-то ещё координатами. Третий — что-ещё. Сама ракета несёт ответственность только за себя. Работа двигателей, работа навигационного оборудования, координаты точки назначения, текущее состояние — это вещи, которые относятся к ракете.
Сложности с тем, использовать глаголы или нет возникают в ситуации, когда предметная область программируемого явления понята не до конца. Вы приписываете самой ракете возможность долбить по какой-то стране, продавать себя и т.п. — это куча явлений, которые к ней не относятся. Они слишком избыточны для ракеты, и вы начинаете в них захлёбываться, пытаясь хоть как-то распихать их по свойствам, придумать для их организации какие-то правила — например, не использовать глаголы.
Именно из-за этого начинают возникать вопросы, вроде: как описать интерфейс ракеты, чтобы её можно было запустить или продать через «/missiles/[missile-id]» в country_id. Её не нужно запускать или продавать через неё саму. Если организовать архитектуру корректно, то у вас даже и мысли не возникнет, чтобы через «/missiles/[missile-id]» это делать. И не возникнет вопросов с тем, как именовать сложные действия. Если возникает ситуация со сложным действием, есть смысл делегировать отдельные шаги этого действия ресурсам, которые имеют соответствующую компетенцию, чтобы сама ракета могла сосредоточиться на процессе полёта и взрыва, а всякие философские вопросы при этом не грузили её процессорное время.
В первую очередь country_id — это не часть объекта missile. Ситуация, когда используется подход POST /missiles/[id]/countries-landed/[country_id] — это примерно то же самое, когда в контроллере, где им совсем не место, пишутся SQL-запросы.
Одно из архитектурных свойств REST — упрощение интерфейсов. Ракета не должна каким-нибудь извращённым способом через REST влиять на популяцию рыбы в Керченском проливе. Через интерфейс ракеты не нужно получать список стран, в которых приземлялись ракеты. Само по себе выражение «countries-landed» извращает смысл и усложняет работу. Countries — это множественное число, которое, к тому же, ограничивает возможные цели ракеты только странами (а ракеты, вообще, должны приземляться на точки с определёнными координатами; «страна» — это вообще слишком большой разброс координат). Landed — это прошедшее время, которое подразумевает уже свершившийся факт. А информация о том, куда ракета продавалась — это информация, которая не связана с функциями ракеты, что вообще засоряет интерфейс работы с ракетой. Когда ракета выполнила свою задачу, информация о ней должна храниться в архивах военной базы, так как после уничтожения ракеты у неё по определению не может быть интерфейса, так как её больше не существует.
В целом, из-за своей природы, компьютер сожрёт что угодно. Можно написать так, что вызов «cancel» будет запускать ракету, а вызов «launch» будет аварийно отключать всю электронику. Человекопонятные названия — это для людей. Значит эти названия не должны извращать смысл действий. «countries-landed» по своему смыслу означает, что нужно вывести список стран, в которых ракета уже приземлялась. В такой ситуации вместо использования одного понятного выражения придётся писать кучу документации, чтобы объяснить, что вы имели ввиду под «countries-landed». К тому же, если вы вызываете country_id, значит у этого конкретного объекта «страна» должны быть все свойства для нормальной работы со странами. Иначе получится, что у вас в одном интерфейсе объект «страна» представлена одним способом, в другом объекте — другим способом, в третьем объекте — третьим способом. И становится вообще непонятно, что это за фигня такая: «страна»?
У ракеты не может быть списка стран, в которых она приземлялась. Ракета имеет одноразовый характер. Если она приземлилась один раз, она больше не будет приземляться ещё где-то, потому что приземление вызывает её уничтожение. Есть смыл использовать «countries-landed» где-то в статистических отчётах о прошедших запусках какой-то военной базы, но это точно не та информация, которая должна храниться в объекте «ракета».
Важно не искажать смысл объекта и не делегировать ему лишних полномочий. То, что в REST-интерфейсе не должно быть глаголов — это фантазии. Если использование глаголов упрощает интерфейс, лучше использовать глаголы, а не плодить кучу мусора, которая выполняет действие с помощью существительных. Это всё-таки не конкурс писателей.
С вашим подходом вообще можно прийти к такому интерфейсу:
Просто иногда важно понимать смысл используемых объектов, чтобы не плодить кучу мусора. Если нужно узнать куда ракета продавалась, лучше делать запрос к интерфейсу с архивом продаж. Если нужно узнать, куда приземлилась конкретная ракета, нужно делать запрос к архиву запусков. А ракета должна только давать интерфейс для оперативного управления ракетой — без лишней информации и без лишней подгрузки справочников стран.
У вас, возможно, была какая-то отличная мысль, но примерами вы эту мысль завели в неправильную сторону. И это совсем не помогает оценить все прелести вашего подхода, так как они искажают смысл.
Но я не знаю, какие там особенности при публикации в блоге компании, которая платит за возможность вести блог. Тем более, копипастили они сами у себя, похоже.
Ещё и полицию добавить нужно. И суды. Чтобы, например, за срыв сроков по проекту отключали всю семью от канализации и электричества. А некоторые уволенные работники будут отказываться покидать свои жилища, потому что считают несправедливым своё увольнение. И так далее.
Просто всё это рождает кучу организационных вопросов и кучу дополнительных сложностей. Чем меньше корпорация лезет в личную жизнь, тем проще выстраивать нормальные деловые отношения. Всё-таки, корпорация — это не друг семьи. Чем больше доступа к личной жизни она имеет, тем больше у неё точек давления на своего работника, тем больше она имеет способов лишать людей независимости.
А про историю комментариев и историю правок на странице пользователя — простите, что повторяюсь и навязываю мысль, но без них жутко неудобно. Если бы такая история была, то мне лично было бы легче понимать, с каким человеком я вступаю в диалог. Комментарии — это активность, сопоставимая с ответами или вопросами, так как во время комментирования человек так же публикует контент. Без такой истории получается, что на странице профиля отражена неполная информация. Точно так же, история правок, которую делает человек — её тоже было бы удобно видеть (не обязательно в виде diff-кода — достаточно ссылки на вопрос, который он редактировал). Она тоже может помочь лучше понять потенциального собеседника.
На странице пользователя не хватает раздела со списком того, какие он делал правки, чтобы можно было быстро перейти на страницу соответствующего вопроса.
Точно так же, на странице пользователя не хватает радела со списком его комментариев. Некоторые пользователи пишут намного больше комментариев, чем ответов на вопросы. Было бы очень полезно видеть их тоже в виде списка.
Текущий вариант правок — его логика — работает хуже, чем мог бы. Получается, что именно человек, который изначально пишет вопрос плохого качества, выступает модератором правок. А человек, который может сделать лучше, должен смиренно ожидать, соблаговолит ли автор вопроса принять его правки или нет. Я считаю, что нужно больше в этом плане доверять сообществу. Правки нужно публиковать сразу же. И нужна возможность если не откатывать чужие правки, то, хотя бы, сообщать о них модераторам.
Подумайте сами, когда создаётся лишняя бюрократическая ступенька в виде автора вопроса, то ни о каком оперативном изменении вопроса и ни о какой коллаборации речи не может идти. Может получиться интересная ситуация, когда несколько человек будут делать одну и ту же правку, так как будут думать, что вопрос опубликован с ошибкой — никто не будет в курсе, что к этому вопросу висят уже 10 запросов на правку, которые меняют «ться» на «тся» или добавляют тег «code» где нужно. Вы таким образом приведёте к тому, что пользователи будут больше тратить времени впустую, чем могли бы. Никто не любит тратить время впустую.
Есть смысл обратиться к адвокатам, чтобы вообще выяснить что считается чистым, а что нет. Я мог бы всё это прогуглить и написать высоконаучный обоснованный ответ, но ценность его будет очень низкая. А за криптовалюты вы так и так не купите домик. Может сложиться такая ситуация, что вы поимеете проблемы ещё на этапе обналичивания биткоинов, особенно если сумма такая большая, как эквивалент 600-700 тысяч долларов.
Но если вы по итогам этого мероприятия напишете статью на Хабр, я думаю много людей будут вам благодарны. Могу только пожелать удачи. ))
В целом, покупать там домик, чтобы сдавать его и потом продавать — это лишний геморрой. Как я писал выше, этот вариант только для ситуации, когда нужно по-резкому получить гражданство, про которое, кстати, власти островов никому не «стучат».
За 500 тысяч можно получить американское гражданство по программе «EB-5 Immigrant Investor». Это более грамотное вложение, мне кажется, так как вложенные деньги вернутся уже через пять лет. При этом, первые 50% — уже через 2 с половиной года. К тому же, американский паспорт лучше котируется в Европе, чем паспорт Нэвиса. И с таким баблищем там больше шансов это баблище ещё приумножить.
Смело умножайте 250 и 400 на полтора-два, чтобы получить примерную стоимость оформления со всеми сопутствующими расходами. Без специализированных адвокатских контор, например, вы точно не обойдётесь, а это не те люди, которые работают бесплатно.
А вы что, серьёзно планируете жить на Нэвисе? За трёхметровым забором и со стаей злых собак для охраны?
За такие деньги, в которые обойдётся гражданство Нэвиса, можно 10 лет жить в Таиланде — в пентхаузе с круглосуточным миньетом.
Гражданство Нэвиса обычно получают люди, вроде семейства Билзерянов или Павла Дурова — которые хотят по-быстрому сменить гражданство из-за проблем с государством и относительно не стеснены средствами, чтобы выкинуть на это 600-800 тысяч долларов. Плюс этого гражданства в том, что оно с минимальными бюрократическими проволочками получается. Ещё один плюс — больше сотни стран, в которые можно без визы въехать по паспорту Сэнт Киттса и Нэвиса. Насчёт того, чтобы жить там постоянно — не очень хорошая идея. С коренным населением вы вряд ли подружитесь. По преступлениям эти два милых островка всё время попадают в десятку-двадцатку рейтинга. Можно на той же википедии посмотреть табличку. Цифрам из вики можно не верить дословно, но примерное представление получить можно.
Я заметил, кстати, что маркетологи часто не могут правильно посчитать число пальцев на руке. Как пример: картинка «6 уровней популярности по Кевину Бэкону» (в оригинале «Six Degrees of Viral Bacon Shares»). Там пять уровней, а не шесть.
Маленький ньюанс: биткоинами вы владеете, а исками — нет. Весь контент в EVE Online принадлежит CCP. И вы заблуждаетесь, если думаете, что «зарабатываете» ISK и «покупаете» кораблик. Вы просто взаимодействуете с игрой. По сути, нет разницы, есть у вас в игре миллиарды иск или десятки титанов — вы имеете к ним доступ только пока оплачиваете подписку. Именно имеете доступ, а не владеете.
Сами подумайте, на чёрном рынке, кроме исков, можно и батлшипы покупать тоже. Они что, тоже от этого автоматом становятся деньгами?
Вопрос, ISK тоже денежный суррогат?
Нет. Чтобы они стали денежным суррогатом, CCP должны для начала передать вам права на их владение. До этого момента их использование для покупки каких-то товаров будет считаться незаконным. Но не с позиции денежных суррогатов, а с позиции нарушения авторского права CCP Games.
У вас просто системная ошибка. Вы думаете, что чужая интеллектуальная собственность и электронные деньги — это одно и то же. И из-за этой системной ошибки вы делаете выводы, которые только выглядят логично, но в корне неверны.
У вас в вашем вопросе на Тостере просто есть ошибки — системные ошибки. Чтобы построить хороший интерфейс, нужно хорошо описать предметную область. Хорошее понимание предметной области очень сильно поможет в реализации всей архитектуры. С точки зрения ракеты, её нельзя запустить по стране или продать в страну.
Верховного Главнокомандующего Страны-Р можно заставить через REST бабахнуть по Стране-А. Это его ответственность и именно он может принимать такие решения, так как является в этой ситуации ключевым ресурсом. Перед тем, как ракета прилетит в Страну-А, произойдёт ещё куча REST-вызовов к различным ресурсам. Один ресурс содержит коллекцию координат, по которым эффективнее всего долбить в конкретной стране. Второй ресурс содержит коллекцию ракет, которые наиболее эффективным образом смогут пролететь от точки с текущими координатами до цели с какими-то ещё координатами. Третий — что-ещё. Сама ракета несёт ответственность только за себя. Работа двигателей, работа навигационного оборудования, координаты точки назначения, текущее состояние — это вещи, которые относятся к ракете.
Сложности с тем, использовать глаголы или нет возникают в ситуации, когда предметная область программируемого явления понята не до конца. Вы приписываете самой ракете возможность долбить по какой-то стране, продавать себя и т.п. — это куча явлений, которые к ней не относятся. Они слишком избыточны для ракеты, и вы начинаете в них захлёбываться, пытаясь хоть как-то распихать их по свойствам, придумать для их организации какие-то правила — например, не использовать глаголы.
Именно из-за этого начинают возникать вопросы, вроде: как описать интерфейс ракеты, чтобы её можно было запустить или продать через «/missiles/[missile-id]» в country_id. Её не нужно запускать или продавать через неё саму. Если организовать архитектуру корректно, то у вас даже и мысли не возникнет, чтобы через «/missiles/[missile-id]» это делать. И не возникнет вопросов с тем, как именовать сложные действия. Если возникает ситуация со сложным действием, есть смысл делегировать отдельные шаги этого действия ресурсам, которые имеют соответствующую компетенцию, чтобы сама ракета могла сосредоточиться на процессе полёта и взрыва, а всякие философские вопросы при этом не грузили её процессорное время.
Одно из архитектурных свойств REST — упрощение интерфейсов. Ракета не должна каким-нибудь извращённым способом через REST влиять на популяцию рыбы в Керченском проливе. Через интерфейс ракеты не нужно получать список стран, в которых приземлялись ракеты. Само по себе выражение «countries-landed» извращает смысл и усложняет работу. Countries — это множественное число, которое, к тому же, ограничивает возможные цели ракеты только странами (а ракеты, вообще, должны приземляться на точки с определёнными координатами; «страна» — это вообще слишком большой разброс координат). Landed — это прошедшее время, которое подразумевает уже свершившийся факт. А информация о том, куда ракета продавалась — это информация, которая не связана с функциями ракеты, что вообще засоряет интерфейс работы с ракетой. Когда ракета выполнила свою задачу, информация о ней должна храниться в архивах военной базы, так как после уничтожения ракеты у неё по определению не может быть интерфейса, так как её больше не существует.
В целом, из-за своей природы, компьютер сожрёт что угодно. Можно написать так, что вызов «cancel» будет запускать ракету, а вызов «launch» будет аварийно отключать всю электронику. Человекопонятные названия — это для людей. Значит эти названия не должны извращать смысл действий. «countries-landed» по своему смыслу означает, что нужно вывести список стран, в которых ракета уже приземлялась. В такой ситуации вместо использования одного понятного выражения придётся писать кучу документации, чтобы объяснить, что вы имели ввиду под «countries-landed». К тому же, если вы вызываете country_id, значит у этого конкретного объекта «страна» должны быть все свойства для нормальной работы со странами. Иначе получится, что у вас в одном интерфейсе объект «страна» представлена одним способом, в другом объекте — другим способом, в третьем объекте — третьим способом. И становится вообще непонятно, что это за фигня такая: «страна»?
У ракеты не может быть списка стран, в которых она приземлялась. Ракета имеет одноразовый характер. Если она приземлилась один раз, она больше не будет приземляться ещё где-то, потому что приземление вызывает её уничтожение. Есть смыл использовать «countries-landed» где-то в статистических отчётах о прошедших запусках какой-то военной базы, но это точно не та информация, которая должна храниться в объекте «ракета».
Важно не искажать смысл объекта и не делегировать ему лишних полномочий. То, что в REST-интерфейсе не должно быть глаголов — это фантазии. Если использование глаголов упрощает интерфейс, лучше использовать глаголы, а не плодить кучу мусора, которая выполняет действие с помощью существительных. Это всё-таки не конкурс писателей.
С вашим подходом вообще можно прийти к такому интерфейсу:
[GET|POST|PUT|DELETE] /missiles/[missile-id]/owner/[country_id]/cities/[city-id]/people/[human-id]/current-wearing
Или к такому:
[POST] /missiles/[missile-id]/owner/[country_id]/bases/[base-id]/missiles/[missile-id]/targets/[target-id]/bases/[base-id]/missiles/[missile-id]/countries-landed/[country_id]
Просто иногда важно понимать смысл используемых объектов, чтобы не плодить кучу мусора. Если нужно узнать куда ракета продавалась, лучше делать запрос к интерфейсу с архивом продаж. Если нужно узнать, куда приземлилась конкретная ракета, нужно делать запрос к архиву запусков. А ракета должна только давать интерфейс для оперативного управления ракетой — без лишней информации и без лишней подгрузки справочников стран.
У вас, возможно, была какая-то отличная мысль, но примерами вы эту мысль завели в неправильную сторону. И это совсем не помогает оценить все прелести вашего подхода, так как они искажают смысл.
Но я не знаю, какие там особенности при публикации в блоге компании, которая платит за возможность вести блог. Тем более, копипастили они сами у себя, похоже.
Просто всё это рождает кучу организационных вопросов и кучу дополнительных сложностей. Чем меньше корпорация лезет в личную жизнь, тем проще выстраивать нормальные деловые отношения. Всё-таки, корпорация — это не друг семьи. Чем больше доступа к личной жизни она имеет, тем больше у неё точек давления на своего работника, тем больше она имеет способов лишать людей независимости.
Точно так же, на странице пользователя не хватает радела со списком его комментариев. Некоторые пользователи пишут намного больше комментариев, чем ответов на вопросы. Было бы очень полезно видеть их тоже в виде списка.
Текущий вариант правок — его логика — работает хуже, чем мог бы. Получается, что именно человек, который изначально пишет вопрос плохого качества, выступает модератором правок. А человек, который может сделать лучше, должен смиренно ожидать, соблаговолит ли автор вопроса принять его правки или нет. Я считаю, что нужно больше в этом плане доверять сообществу. Правки нужно публиковать сразу же. И нужна возможность если не откатывать чужие правки, то, хотя бы, сообщать о них модераторам.
Подумайте сами, когда создаётся лишняя бюрократическая ступенька в виде автора вопроса, то ни о каком оперативном изменении вопроса и ни о какой коллаборации речи не может идти. Может получиться интересная ситуация, когда несколько человек будут делать одну и ту же правку, так как будут думать, что вопрос опубликован с ошибкой — никто не будет в курсе, что к этому вопросу висят уже 10 запросов на правку, которые меняют «ться» на «тся» или добавляют тег «code» где нужно. Вы таким образом приведёте к тому, что пользователи будут больше тратить времени впустую, чем могли бы. Никто не любит тратить время впустую.
Но если вы по итогам этого мероприятия напишете статью на Хабр, я думаю много людей будут вам благодарны. Могу только пожелать удачи. ))
За 500 тысяч можно получить американское гражданство по программе «EB-5 Immigrant Investor». Это более грамотное вложение, мне кажется, так как вложенные деньги вернутся уже через пять лет. При этом, первые 50% — уже через 2 с половиной года. К тому же, американский паспорт лучше котируется в Европе, чем паспорт Нэвиса. И с таким баблищем там больше шансов это баблище ещё приумножить.
За такие деньги, в которые обойдётся гражданство Нэвиса, можно 10 лет жить в Таиланде — в пентхаузе с круглосуточным миньетом.
Гражданство Нэвиса обычно получают люди, вроде семейства Билзерянов или Павла Дурова — которые хотят по-быстрому сменить гражданство из-за проблем с государством и относительно не стеснены средствами, чтобы выкинуть на это 600-800 тысяч долларов. Плюс этого гражданства в том, что оно с минимальными бюрократическими проволочками получается. Ещё один плюс — больше сотни стран, в которые можно без визы въехать по паспорту Сэнт Киттса и Нэвиса. Насчёт того, чтобы жить там постоянно — не очень хорошая идея. С коренным населением вы вряд ли подружитесь. По преступлениям эти два милых островка всё время попадают в десятку-двадцатку рейтинга. Можно на той же википедии посмотреть табличку. Цифрам из вики можно не верить дословно, но примерное представление получить можно.
Но, в целом, статья интересная.
Так он новый или не новый?
Но хабы всё-таки называются хабами.
Сами подумайте, на чёрном рынке, кроме исков, можно и батлшипы покупать тоже. Они что, тоже от этого автоматом становятся деньгами?
Нет. Чтобы они стали денежным суррогатом, CCP должны для начала передать вам права на их владение. До этого момента их использование для покупки каких-то товаров будет считаться незаконным. Но не с позиции денежных суррогатов, а с позиции нарушения авторского права CCP Games.
У вас просто системная ошибка. Вы думаете, что чужая интеллектуальная собственность и электронные деньги — это одно и то же. И из-за этой системной ошибки вы делаете выводы, которые только выглядят логично, но в корне неверны.