Microsoft вроде всё больше и больше поворачивается лицом к Linux уже не первый год, а какая Adobe принципиальная разница на чём гоняют их софт вообще не понятно, мне кажется они только из «лени» Linux не поддерживают — не хотят тратиться на поддержку столь малопопулярной среди их целевой аудитории платформы т.к. вряд ли окупится.
На дэсктопе — Linux, на лэптопе (всё таки MacBook Air хорош) — Макось, не вижу никакой проблемы, у самого так. Отстаньте от Джима, не будьте как Билл Гейтс, который по слухам отбирает у своих детей айфоны и заставляет пользоваться виндофонами :-)
Вообще меня завораживает мысль об игре, более-менее глубоко воспроизводящей идею Фллоаута в таком вот формате. Оригинальный Фоллаут по сути сочетал в себе интересную и душевную книгу, обширный интерактивный мир в котором можно жить и навороченный «рогалик» с очень атмосферной графикой. И мне кажется, что по первому и второму пунктам (а именно они мне кажутся главными, интерес к обшариванию ветвистых корридоров и истреблению толп монстров в них у меня лично пропал достаточно быстро, хотя многие, наверно, как раз такое любят) можно сделать на уровне и переплюнуть запросто, достаточно чуточку допилить движок и попробовать затянуть в команду несколько писателей более-менее адекватных фанфиков с тематических форумов. А если плюс к этому ещё удастся найти художников, которые нарисуют атмосферных иллюстраций (способных на это на самом деле не так уж мало), то вообще будет бомба.
Взаимно приятно :-) Вообще Oregon Trail Deluxe 1992-го года прекрасно скачивается по первой же ссылке из Гугла (myabandonware) и легко запускается через CrossOver на Маке. Провёл за ним в обнимку с девушкой несколько невероятно уютных вечеров :-) (а вот Oregon Trail II, например, уже показалась черезмерно усложнённой). Подумал тогда что надо будет как-нибудь написать что-то подобное. Рад, что в опенсорсе появился такой проект. Но мне кажется надо будет только всё-таки слегка усложнить-детализировать игровую модель, увеличить мир и добавить сюжетную составляющую и может выйти что-то очаровательное. Очень здорово, что в основу заложена идея отделения данных от движка, так что в будущем не-программисты смогут достаточно легко вносить вклад в обогащение игрового мира.
Да, интересненько. Отдалённо напоминает тёплвй ламповый Oregon Trail. Было бы клёво добавить сюжетностей, NPC со своими вызывающими сопереживание историями и возможностью осмысленного общения, всего такого, добавить какой-то атмосферный арт и может весьма уютная штука выйти.
Справедливости ради следлвало бы отметить зачем тогда вообще нужен тип double когда есть decimal: математические операции производятся над decimal очень намного медленнее (сам точно разницу не замерял, только на глазок, но давеча видел где-то коммент, что примерно в 100 раз). Аппаратная поддержка десятичных типов вроде есть только в процессорах IBM начиная с POWER6.
Среди многих почему-то бытует мнение, что работать из дома — это какая-то превилегия, которую нужно заслужить. На самом деле, я бы сказал, наоборот: в офисе компания обеспечивает тебе рабочее место — собственно место (аренда), стол, кресло, комп, интернет, обеды, отсутствие отвлекающих факторов — это всё стоит денег, а удалённый сотрудник обходится компании дешевле, но ему приходится самому обустраивать себе комфортное рабочее место и это не всегда просто. В одной из компаний, с корорыми я работал сотрудников как раз мотивировали (повышением зарплаты при той же производительности) переходить на удалёнку чтобы не занимали место в офисе. Если тебе дают возможность пользоваться комфортным рабочим местом в уютном офисе с удобным расположением — это круто и ради этого можно даже согласиться на чуть меньшую зарплату, но когда из этого делают обязаловку и начинают пристёгивать тебя «наручниками к стулу» (что актуально для рабов на галерах/конвеерах, но не для интеллектуального труда), обращаться как со школьником, которому нужен постоянный родительский надзор, заставлять чувствовать вину и рабскую благодарность, выпрашивая возможность остаться дома всякий раз, когда тебе того хочется/требуется — это вызывает живейший внутренний протест и демотивирует.
Ввиду недавнего решения Red Hat будущее BTRFS уже слегка как бы под вопросом. Посмотрим. Надеюсь выживет и будет развиваться, альтернативы и здоровая конкуренция — это классно.
Спасибо за статью. Интересная и важная тема. Но лично я бы поставил задачу продления жизни в принципе и борьбы со смертью на второй план, а на первый — задачу продления молодости и борьбы с характерными симптомами процесса старения (в первую очередь кожи, мозга, имунной системы, физической выносливости, механизмов восстановления после травм и т.п. — то, что, собственно, на практике отличает старого человека от молодого), чтобы не получилось как в том анекдоте «жить будете, но разве это жизнь?». Прожить несколько лишних десятков лет в теле дряхлого старика — сомнительное достижение, ценность в котором увидит, мне кажется, не каждый, а вот дожить, скажем, до шестидесяти в теле здорового 30-летнего — вот это было бы реально классно, даже если после этого сразу умрёшь.
При резких неблагоприятных колебаниях цен все 100% майнеров выключат оборудование. На плаву останутся, разве что, те, кто пользуется бесплатным электричеством. В этом случае работа сети просто остановится – на доработку «двух недель» потребуется время, соизмеримое с жизнью, а невозможность проведения транзакций еще больше опустит цену биткойна.
Я так понимаю достаточно хорошего обвала (типа тех, что периодически случаются на фондовых биржах), который как-следует напугает майнеров и спровоцирует «медведей» достаточно чтобы превратить драгоценные биткойны в кошельках инвесторов в застывшие цифры, с которыми ничего невозможно сделать, т.е. полностью их обесценить.
Ещё интересно правильно ли я понял, что уже сейчас имеющий BitCoin уже не может просто взять и спонтанно заплатить ими за чашку кофе т.к. транзакция займёт не один день?
Кстати посоветуйте что почитать/посмотреть чтобы хорошенько вкурить async/await с полного нуля для человека, который всю жизнь использовал для параллелизации только BackgroundWorker (ну и ещё пару раз немного Akka), а теперь хочет перейти на более современное и портабельное и понять как следует, чтобы перестать думать ивентами, начать думать тасками и научиться применять их правильно и по-полной. Заранее спасибо.
Таким образом, чтобы написать Generic Repository нужно:
Собраться с мыслями.
Спроектировать интерфейс.
Написать реализацию под выбранный в проекте ORM.
Написать реализацию под альтернативные ORM
…
А зачем вообще в таком случае использовать какую бы то ни было ORM? Почему бы просто не использовать запросы на чистом SQL в реализации самого репозитория в таком случае? Не холивара ради пишу, реально не понимаю и хочу понять. Традиционный аргумент о привлечении дополнительного слоя абстракции ради независимости от конкретных СУБД вроде как не в счёт т.к. всё-равно у нас есть пункты «Спроектировать интерфейс» и «Написать реализацию под альтернативные ORM».
Пороблема эмодзи в том, что у всех они отображаются по разному и один и тот же символ с одним и тем же кодом в разных приложениях, а то и в разных скинах для них может передавать совершенно разные чувства. Вероятность того, что увидев эмодзи ты почувствуешь то же, что чувствовал и что хотел передать отправитель как правило стремится к нулю. В этом плане даже картинки-мемы и то лучше.
Почасовая оплата умственного труда — это ужасно, по возможности избегайте этого. Крайне печально, что народ тащит эту архаичную, придуманную для конвеерных и тому подобных рабочих схему в IT, где она совершенно неадекватна.
Для андроид тоже предпочтительней будет использовать не CUBIC, который лучше работает на Long Fat Network, а для беспроводных протоколов будет лучше выбрать что-то другое, например, Westwood.
А почему нельзя сделать это переключаемым на уровне пользователя? Чтобы либо вручную можно было легко и быстро сделать такой «твик», либо автоматически в зависимости от типа соединения? Я, например, с андроидофона в Сеть выхожу исключительно по WiFi, нормальные люди вроде тоже большую часть времени проводят в офисе и дома, где кабельный/DSL канал раздаётся через WiFi и периодически ненадолго переключаются на GPRS/3G/LTE.
Рад, что хоть кто-то заметил. Тем не менее все почему-то помнят в лучшем случае о странах, при этом забывают, что для каждого штата/земли/республики/области/итп тоже есть ISO-код по стандарту ISO 3166-2. Таким образом мы фактически имеемт все страны и их териториальные подразделения перечисленными и кодифицированными в стандарте, на самодеятельность остаются только непосредственно населённые пункты (города, посёлки, деревни и т.п.).
В Германии (2080) больше городов, чем в США (1591)? Серьёзно? Банальный запрос «number of cities in the us» выдаёт «As of 2013, the United States has 3,007 counties and 137 county equivalents for a total of 3,144 counties and county equivalents. Cities and towns: According to the U.S. Census Bureau, there are 19,354 „incorporated places“ in the United States.» Т.е. одних только «графств» (county — следующий уровень административного деления после штата, в одном county может быть несколько городов) там 3144 штуки а населённых пунктов вообще 19354.
Ещё мне кажется такой базе следовало бы включать стандартные коды стран по ISO 3166-1 alpha-2 и (например Россия — RU, США — US, Великобритания — GB и т.д.) и стандартные коды регионов («штатов») по ISO 3166-2 (например Алабама — US-AL, Алтайский край — RU-ALT, Полтавская область — UA-53 и т.д.).
Я так понимаю достаточно хорошего обвала (типа тех, что периодически случаются на фондовых биржах), который как-следует напугает майнеров и спровоцирует «медведей» достаточно чтобы превратить драгоценные биткойны в кошельках инвесторов в застывшие цифры, с которыми ничего невозможно сделать, т.е. полностью их обесценить.
Ещё интересно правильно ли я понял, что уже сейчас имеющий BitCoin уже не может просто взять и спонтанно заплатить ими за чашку кофе т.к. транзакция займёт не один день?
А зачем вообще в таком случае использовать какую бы то ни было ORM? Почему бы просто не использовать запросы на чистом SQL в реализации самого репозитория в таком случае? Не холивара ради пишу, реально не понимаю и хочу понять. Традиционный аргумент о привлечении дополнительного слоя абстракции ради независимости от конкретных СУБД вроде как не в счёт т.к. всё-равно у нас есть пункты «Спроектировать интерфейс» и «Написать реализацию под альтернативные ORM».
А почему нельзя сделать это переключаемым на уровне пользователя? Чтобы либо вручную можно было легко и быстро сделать такой «твик», либо автоматически в зависимости от типа соединения? Я, например, с андроидофона в Сеть выхожу исключительно по WiFi, нормальные люди вроде тоже большую часть времени проводят в офисе и дома, где кабельный/DSL канал раздаётся через WiFi и периодически ненадолго переключаются на GPRS/3G/LTE.
Рад, что хоть кто-то заметил. Тем не менее все почему-то помнят в лучшем случае о странах, при этом забывают, что для каждого штата/земли/республики/области/итп тоже есть ISO-код по стандарту ISO 3166-2. Таким образом мы фактически имеемт все страны и их териториальные подразделения перечисленными и кодифицированными в стандарте, на самодеятельность остаются только непосредственно населённые пункты (города, посёлки, деревни и т.п.).
В Германии (2080) больше городов, чем в США (1591)? Серьёзно? Банальный запрос «number of cities in the us» выдаёт «As of 2013, the United States has 3,007 counties and 137 county equivalents for a total of 3,144 counties and county equivalents. Cities and towns: According to the U.S. Census Bureau, there are 19,354 „incorporated places“ in the United States.» Т.е. одних только «графств» (county — следующий уровень административного деления после штата, в одном county может быть несколько городов) там 3144 штуки а населённых пунктов вообще 19354.
Ещё мне кажется такой базе следовало бы включать стандартные коды стран по ISO 3166-1 alpha-2 и (например Россия — RU, США — US, Великобритания — GB и т.д.) и стандартные коды регионов («штатов») по ISO 3166-2 (например Алабама — US-AL, Алтайский край — RU-ALT, Полтавская область — UA-53 и т.д.).