Так ли мёртв ПК? 20 лет споров

Сериалы вдвоем не смотрим… Ну как не смотрим: я, после того как жену завел, сериалы перестал смотреть, потому как начал их слушать. Включает моя какой-нибудь новый сериал, а я сижу, тупляю в ноут и на фоне там какой-то экшн происходит.

По поводу общения — несогласен, я много времени я провел, тыкая в клаву айпада, и поэтому могу сказать что тактильного подтверждения хоть и нет, но от него отвыкаешь достаточно быстро и потом уже совершаешь достаточно малое количество ошибок, за которые хочется ненавидеть экранную клаву.

Так ли мёртв ПК? 20 лет споров

Лично я практически никаких трудностей в отсутствии шумящей коробки на w8 уж точно не испытываю. Все опять же упирается в игры и специфичный софт. Игр под мак маловато, поэтому если бы играл, то наверное, испытывал проблемы. А со всякими офисами и фотошопами (вот сейчас мне его не хватает, после сегодняшней фотосессии) — беда в том, что их надо покупать второй раз.

Так ли мёртв ПК? 20 лет споров

1. Совершенно нормально. По крайней мере сериалы. Фильмы, если смотрим вдвоем, то смотрим уже в кино — это кстати основная причина того, почему у меня до сих пор нет огромного телевизора на всю стену. Банально не нужен.

2. Можно, и моя так делает, но есть два но: скорость и качество.

3. Нет. А если и приходится то очень редко. Но для этого есть на айпаде есть pages и numbers + если уж совсем много текста необходимо набрать, то можно достать синезубую клаву из тумбочки.
На ноуте для этого — гуглдоки, которых хватает практически для всего. Если уж совсем-совсем — то ремоут декстопом к компу, там имеется полноценный офис.

4. На айпаде тоже имеются нормальные игры, хотя, смотря что считать нормальными играми. Но проблем во что бы поиграть практически не возникает. Да и в целом мы играем мало.

Так ли мёртв ПК? 20 лет споров

К примеру можно взять мою жену. Не так давно (еще когда на дворе была весна...) мы остались без монитора у домашнего компа… Почему я до сих пор не прикупил сей весма нужный девайс?

Потому что домашний комп нам просто не нужен.

Что мы имеем сейчас: мой рабочий ноут (который большую часть времени со мной на работе) и «уже ставший ее личным» айпад. Так вот айпада, для ее задач хватает практически полностью. Общатся, играться, смотреть фильмы-сериалы. Что еще нужно обычному человеку далекому от айтишности? Да ничего. Единственное для чего она отнимает у меня переодически ноут — для загрузки сериалов. К сожалению тут все упирается в торренты.

Преобразование асинхронных методов в синхронные с возвращением результата в Java

Вот кстати еще один вариант, который чуточку короче:

class A {
    public void asyncMethod(final Callback callback) {
        newFixedThreadPool(1).execute(new Runnable() {
            @Override
            public void run() {
                parkNanos(TimeUnit.SECONDS.toNanos(5));
                callback.onFinish("Finished!");
            }
        });
    }



    public Object syncMethod() {
        final Exchanger<Object> ex = new Exchanger<Object>();

        asyncMethod(new Callback() {
            @Override
            public void onFinish(Object o) {
                try {
                    ex.exchange(o);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });


        try {
            return ex.exchange(null);
        } catch (InterruptedException e) {
            e.printStackTrace();
            return null;
        }
    }
}

Изменения внутреннего представления строк в Java

Потому что строки, полученные методом intern() попадают в PermGen

Изменения внутреннего представления строк в Java

Есть хорошая вероятность, что все эти ваши строки очень хорошо соберутся в стадии concurrent-mark и concurrent-sweep, при условии что мы их выкидываем, а если постоянно держим, то опять же, висят и висят, никого не трогают

Изменения внутреннего представления строк в Java

Как известно, класс Random не очень дружелюбен с многопоточностью: он содержит поле private final AtomicLong seed. Atomics работают неплохо при средней нагрузке, но плохо при большой нагрузке.
Во-первых, с чего это Atomic* — это «не очень дружелюбен с многопоточностью».
Во-вторых, атомики работают плохо при рейс кондишне, и, я не знаю что нужно делать, что бы созданием таких объектов как мапы забить cas до состояния, когда на нем просядет производительность.

Изменения внутреннего представления строк в Java

Замечательное решение что бы убить приложение.

5 причин, по которым freemium-игры «всасывают»

Имея доступ к статистике нескольких, достаточно популярных игр, могу сказать, что такие специфичные вещи покупают единицы, которые уже купили все остальное

5 причин, по которым freemium-игры «всасывают»

Невозможно сделать нормальную сбалансированную мультиплеерную игру с ENH

5 причин, по которым freemium-игры «всасывают»

Судя по трем пунктам — вы не являетесь целевой аудиторией большинства игр.
И… что для вас «интересный и разнообразный геймплей» в контексте одной игры.

5 причин, по которым freemium-игры «всасывают»

Я вот тоже первый год думал — что ну нафиг платить в f2p играх, развод на деньги и прочее. Но, реальность есть реальность и сейчас можно найти очень много адекватных, затягивающих и интересных игр, в которые можно вложить деньги. 170-340 рублей будет достаточно (если агресивно плюшки не использовать) для того, что бы упроситить себе жизнь.

В последнее время все меньше и меньше (опять из того, что мне интересно) выходит игр, которые при входе в игру начинают агресивно высасывать из меня денег. Если вы скейчас посмотрите на первые пять игр (исключая казуалки) из top grossing в app store, то увидите, что им не нужен жесткий прессинг пользователя что бы он платил. Это ложиться на плечи других игроков и на некоторые искусственные ограничения, которые можно обойти либо задроством, либо донатом.

Тонны баннеров со «скидки-скидки-скидки» постепенно будут вытеснятся играми с нормальным балансом и хорошим геймплеем

5 причин, по которым freemium-игры «всасывают»

И кто будет «донатить» в игру, где ему не дается реальных, ощутимых плюшек?

5 причин, по которым freemium-игры «всасывают»

Баланс… что такое баланс? что игрок А и игрок Б потратив одно и тоже время будут примерно в равных условиях? Наверное. Тогда во многих играх баланса нет. Но всем насрать, люди играют в игры потому что они хотят получать от игры какие то плюшки, если брать всякие мморпг — то самоутвердиться (в большинстве своем).

Сама система f2p не вчера появилась, когда я еще шпынявкой бегал по компьютерным клубам, некоторые мои друзья продавали шмот и персов в разных играх. Спрос всегда был. То, что сейчас эта модель превратилась в массе своей в назойливую тормошилку карманов… ничего, пройдет скоро. Хотя и сейчас есть игры, где f2p присутсвует во всей красе — но, можно и без него хорошо нагибать и радоваться жизни, правда раз в день, потом откладываем игру — кулдауны…

Так вот, точка зрения что каждый игрок должен жить внутри маленького игрового мира и вкладывать только свое время — она, знаете ли, слишком однобока. Я, как и многие казуалы, к примеру не хочу тратить два часа жизни на дрочь. Не хочу. Но во многих играх меня заставляют. Зачастую эти игры бросаются казуалами — если моих скилов не хватает что бы пройти какой-то уровень, то со временем желание проходить его пропадает и, примерно через неделю — я бросаю игру и уже никогда к ней не возвращаюсь.

Поэтому я, так же как и многие эти казулы, готов потратить немного моего ресурса, производного от времени, и помочь самому себе. Это еще и выгоднее будет.

И да, кстати, я пока еще не видел игр (может конечно такие есть, я далеко не во все говно стараюсь играть), в которых казуальщик заплатив к примеру 2-3 сотни баксов станит сверхнагибатором. Не выгодно это с точки зрения гд и получения прибыли.

Стартап-ловушка

Я считаю TDD тяжелой практикой (хотя сейчас на нашем основном проекте, мой код покрыт тестами на 40-70%), потому что за последние пять лет, практиковал TDD в нескольких компаниях, с совершенно разным подходом к разработке и количеством разработчиков на проекте от одного меня, и до семи (где я был ведущим или обычным разработчиком). И сейчас дома поднимаю небольшо й проект… в котором тесты появятся не раньше чем через 1-2 месяца (при той скорости разработки, которую я сейчас стараюсь поддерживать). Причин этому несколько:
1. Тесты отнимают время: Так за все эти пять лет никто не заметил, что тесты ускоряют написание кода. По сути плевать как будет писаться код — сначала код, потом тыкаем проверяем, а потом правим баги, либо вначале пишем тесты, а потом уже пишем код и правим баги. Тут такая ситуация, что если кусок кода не рабочий, и проще его проверить визуально при помощи echo\println или пройтись при помощи дебагера по нему (или что там у вас в языке) — то любой разработчик будет делать именно так. Причем тут не важно есть ли кусок кода на этот ест или его нет. Тест уже отработает потом. Причем то, что он пройдет вот не гарантирует стопроцентно, что код рабочий (привет продакшн в роли тестовой площадки, шесть утра и пять коктелей пина колады, которые помогли мне примерно за четыре часа отыскать косяк на код, который был покрыт тестами более чем на 9000%)

2. Тесты усложняют рефакторинг (да, при этом мы имеем некоторые гарантии на то, что после рефакторинга все работает так, как мы и задумывали). Иногда код приходиться рефакторить по методу «выкини все, что у тебя есть и напиши заново, при этом ничего не сломав». Больше кода — больше переписывать. Тесты это тот же код.

3. Есть такие сиутация где тесты ничего не решаеют. Об этом я писал в соседнем топике.

4. Тесты — это скучно, особенно при рефакторинге. Я не знаю людей которые бы сказали наоборот, что-то вроде «я люблю писать тесты потому что это круто! это весело и делает меня умнее». Нет, самый лучший тест — это самый тупой код, который может быть, который проверяет, а правильно ли работает твой самый замороченный код. Есть такие люди которые пишут тесты «с изюминкой». Говно это а не тесты, на большую часть из них придется еще одни тесты писать потому как тесты не работают.

Остальные причины, по крайней мере для меня, такие как: опыт написания тестов (не все умеют писать тесты) — менее важные, поэтому я их даже не стал расписывать.

Теперь почему я сейчас пишу проект без тестов (почти, есть некоторые тесты на куски кода, которые я просто не знал как написать и поэтому писал вместе с тестами. Покрытие менее 10%). Хотя они опять же появятся там, но чуть позже. Все очень просто — мне важна скорость. Мне нужно к концу месяца выдать готовый продукт, который примерно работает. Учитывая что сейчас у меня 5-й прототип, в котором опять было переписано примерно 70% кода — в этом есть смысл. Старый код, который не работает начинает работать потому как он у меня всегда на виду и я его уже правил несколько раз и багов в нем не осталось. А если и остались, то может быть через пару недель, когда я опять все перепишу и добавлю пару новых фишек — они вылезут и я их поправлю.

О техническом собеседовании

Так и многопоточность — да, важный и ответственный стек технологий, но все ли в команде должны его знать на зубок? Достаточно одного эксперта, который сделает эту работу или научит остальных.

Научить мыслить в рамках многопоточности — достаточно сложно, это долгий процесс, который длится месяцами, если хорошо прикладывать к этому усилия, либо годами, если воспринимать это «раз надо, то надо».

С одним экспертом схема прогорит, если у вас изначально софт многопоточный. Допустим пишете вы игровой сервер, хорошо, если у вас все запросы от пользователя изолированы — много дров не наломаете (хотя конечно можно и постоянно дедлоки ловить), а если начинается взаимодействие между пользователями… то без понимания как должно происходить это взаимодействие мы получим ну просто замечательную картину, когда ничего не работает и никто не знает ничего.

О техническом собеседовании

Оглянулся, за последнюю неделю-две одна рутина — багофиксы и прочие «ах, вот еще забыли про ...». Релиз же скоро. До этого я уже и не помню когда мой день не начинался с мысли «И так, как бы зафигачить…

И кстати, мир вебом не ограничивается.

О техническом собеседовании

шанс найти специалиста подходящего вам априори крайне, крайне мал
В Москве такая же проблема, если вам нужен специалист, со знанием, хоть каким-нибудь, concurrency например (я сейчас про java). EE-шников — до жопы, но, увы, у них строение мозга такое, что они привыкли брать три-четыре-магические-буквы технологию\фреймворк и использовать его, а не думать своей головой.

Да и любят они, знаете ли, взять таску и обсасывать ее неделю, думая как же ее лучше сделать, как покрасивше прикрутить — в их мире, где им по каждому требованию выдают нужное количество серверов, где все проблемы с бд решаются — а почему не Оракл, да и две недели в месяц можно сидеть в потолок плевать — это норма.

О техническом собеседовании

Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать
Далеко не факт что улучшить. Для примера возьмите знакомый вам код, который хорошо так по gc бьет и поиграйтесь с параметрами. Если у вас за плечами нет хорошего опыта по оптимизации всего этого, то думаю вы и через час и через два будете методично возвращаться туда, оттуда начинали оптимизацию*. А уж на собеседовании заниматься такими вещами. Думаю что тогда следующие вопросы будут в духе: укажите в данном коде ребра happens-before

* если конечно проблема не решиться уж совсем тривиальными способами, к примеру переходу к CMS + ParNew и/или увеличению yg.