• Попиксельная заливка экрана в Wolfenstein 3D
    +9
    Наверное, как-то так.
    Правда, только двумя массивами, без битовой магии, вроде той, что описана в статье, вряд ли получится добиться однородного распределения. А вот четырьмя (как в моей демке), получается неплохо.
  • Попиксельная заливка экрана в Wolfenstein 3D
    +4
    Не обязательно 320x200 хранить. Достаточно 320x4: вот, набросал на скорую руку демку.
  • ITренировка — актуальные brain teaser'ы ведущих компаний
    0
    2. Отсортировать и простейший бинарный поиск. А для большого количества длинных слов оптимально использовать Trie.

    3. Неверно. Решение в два прохода и O(N) дополнительной памяти.

    4. Если честно, я не понял условие. Объясните?
    Если требуется посчитать количество атомов каждого элемента в формуле, то как, например, «Fe» влезет в ключ типа `Character`?

    5. Из контекста очевидно, что «прогул» также считается «опозданием», и что учитываются только три опоздания подряд.
    Интерес представляет дополнительная часть при таком условии. Может быть, можно придумать аналитическую формулу, но я бы решал ее динамикой.
  • Как запустить ClickHouse своими силами и выиграть джекпот
    +1
    А что ты считаешь real-time аналитикой? Например, почему кафка+вертика не может быть real-time?
  • Вставка в середину: ArrayList против LinkedList
    +8
    Очень экзотичный сценарий вы выбрали для исследования.

    Если задача — единожды вставить элемент в середину списка, то, по сути, не важно, какая реализация списка используется — обе операции будут O(n).

    Если задача — вставлять элементы в середину в цикле (как делаете это вы в своем тесте), то логично использовать для этой цели LinkedList через ListIterator, так как в этом случае каждая вставка будет O(1).

    Если же задача предполагает вставку элементов в разные «случайные» места по сложной логике, то, опять же, логично будет за один проход расчитать будущие позиции, затем создать на их основе новый список (примерно как это делается при сортировке подсчетом).
  • «Перегрузка операторов» в Scala
    0
    Спасибо за статью, узнал кое-что новое (Infix types) и повторил старое, но редкоиспользуемое.

    Парочка замечаний:
    • В примере с факториалом точка с запятой нужна, чтобы компилятор не искал «второй» операнд на следующей строке. Альтернатива странно смотрящейся точке с запятой будет просто одна пустая строка перед «println».
    • Почему-то в начале статьи вы пишете implicit с «d» на конце
    • Я знаю, что в комментариях не принято писать о TYPO, но все же, исправьте «type constcructor»

  • OMG Scala is a complex language!
    +2
    Мой комментарий следует читать иронично. Я подразумевал как раз то, что вы озвучили:
    вы будете и си называть препроцессором ассемблера?

    Где грань между «синтаксическим сахаром» и фичей, которая позволяет использовать новый подход в программировании?

    Простой пример, ленивая инициализация.
    В Java я ее использую только тогда, когда затраты на ее написание оправданы. Хотя, если задуматься, то это очень мощный механизм, который иногда дает хороший прирост производительности и уменьшает затраты памяти. В Scala это одно ключевое слово «lazy». С его использованием нет проблем, оно не мешает читаемости кода. Таким образом, выходит, что Scala поощряет использовании такого подхода, а Java — нет. Хотя, фактически, синтаксический сахар.
  • OMG Scala is a complex language!
    0
    Не понял, что именно не сработает?
  • OMG Scala is a complex language!
    0
    Так скала по сути и есть препроцессор, который обрабатывает наш код так, как надо (+ либы).
  • OMG Scala is a complex language!
    0
    Еще пара мыслей по поводу equals/hashCode в java и scala:

    В java существуют определенные правила и соглашения, как нужно писать equals/hashCode. В 99% случаев при написании приложений и необходимости переопределять equals/hashCode приходится генерировать «стандартный» код с помощью IDE. Более того, обычно необходимость написания equals/hashCode нестандартно или в нарушении conventions сигнализирует о недостатке дизайна приложения.

    Так вот, то, что в java приходится делать средствами IDE, причем каждый раз заново при изменении сигнатуры класса, в Scala отдали на откуп компилятору. Причем то, что case class запрещено наследовать решает проблему работы equals/hashCode при наследовании.
  • OMG Scala is a complex language!
    0
    Например, так:
      case class CDate(ms: Long) {
        def +(i: Long) = new {
          def day = CDate(i * 1000 * 3600 * 24 + ms)
        }
      }
    
      val now = CDate(System.currentTimeMillis())
      val nowWithDayAdded = now + 1 day
    


    Этот способ не лишен недостатков, например, не получится написать
      val someTimeInFuture = now + 1 day + 1 day
    
  • OMG Scala is a complex language!
    +2
    То, что вы написали и case class — не одно и то же. Ключевое слово «case» автоматически добавляет в класс множество полезных вещей, превращающий объекты этого класса в универсальные DTO.
    Навскидку, генерируется конструктор, equals/hashCode, apply/unapply (для pattern matching), copy (очень полезный аналог clone), toString. И, кстати, case classes are immutable.
  • OMG Scala is a complex language!
    0
    Вы правы в том, что Скала позволяет легче выстрелить себе в ногу.

    Это верно и для перегрузки операторов. Но если не злоупотреблять, то можно получить довольно красивые вещи, например,
    val tomorrow = today + 1 day
  • OMG Scala is a complex language!
    0
    Checked исключений нет, потому что Scala пропагандирует принцип «let it fail» (inspired by Erlang). То есть, если вы явно видите, что определенные ваши действия могут привести к исключению, и вы можете его обработать «на месте», то вы его обрабатываете, в противном случае исключение уходит «наверх», где кто-нибудь о нем позаботится, будь это caller или servlet container.
  • 8 вещей, из-за которых не стоит жить в Силиконовой Долине
    +1
    Кстати, я, кажется, понял, почему автору не понравилась погода. Если автор жил в Сан Франциско — то да, погода там не очень. Постоянные туманы, холодно и дождливо даже летом. Но это только в Сан Фране, в остальной долине это не так :)
  • 8 вещей, из-за которых не стоит жить в Силиконовой Долине
    +1
    Я прошу прощения за ошибки, опечатки и битые ссылки, я плохо выспался :)
    Yosemite
    Point Lobos
  • 8 вещей, из-за которых не стоит жить в Силиконовой Долине
    +18
    По-моему, некоторые «недостатки» надуманные.

    1. Цены на недвижимость.
    Да, они выше, чем в среднем по штатам и рассчитаны на IT специалистов с высокими зп. Но дом можно купить и за вменяемые деньги, если не гнаться за престижным районом. К тому же, если важно именно купить дом, а не, например, снимать аппартменты, то можно рассмотреть вариант ипотеки, ставка по которой гораздо более вменяемая по сравнению с Украиной или Россией.

    2. Налоги.
    Налог в 25-30% выглядит диким для человека, который привык не платить ничего. Но, во-первых, в долине, просто посмотрев вокруг, вы видите, что налоги не пропадают в чьем-то кармане, во-вторых, «высокий налог» для наемного работника — это иллюзия, связанная с неправильной точкой зрения. Просто мысленно уменьшайте зарплаты на 25%, точно так же, как делаете с ценой без НДС в магазине.

    3. Погода и природа
    Я не понимаю, как можно считать погоду в долине недостатком. Всегда комфортная температура (до 25°С днем летом и 12°С днем зимой). Дожди в основном зимой. В часе езды в одну сторону — океан (в 4+ часов езды, если хочется купаться), в 4-х часах езды в другую сторону — снежные горы. В часе езды куча заповедников с огромными редвудами и секвоями.
    Те «выжженные пустоши», что на приведенной картинке — это похоже на Golden Hills. А как насчет пейзажей из действительно красивых мест, вроде Point Lobos, Yosemite? В целом же природа в долине очень необычна и разнообразна. В «деревнях» обычно все усажено зеленью, хайвеи часто усажены по бокам цветами и проходят через живописные леса.

    4. Радикалы
    По-моему, пункт надуманный. Если вы начинаете высказывать странные взгляды, то закономерно будете считаться странным человеком. Другое дело, что в Калифорнии за ваши странные взгляды вас вряд ли побьют, как это может произойти в «более диких странах».

    5. Инфраструктура
    Да, есть определенные проблемы. Хайвеи старые, им более 50 лет, за это время появилось множество выбоин, которые, почему-то, не спешат заделывать. Есть пробки в час пик. Но есть и положительные моменты. Если говорить только про личный транспорт, то есть выделенная полоса (carpool) для экологичных машин и мотоциклов. В час пик она движется довольно резво. Выбирайте, или хотите 5 литров под капотом или быстро ездить в час пик. Или мотоцикл. В долине рай для мотоциклистов. Во-первых, карпулы, во-вторых, нет снега и мало дождей. В-третьих, не запрещено ездить между полосами.
    Кроме этого, еще есть caltrain, для кого-то он может быть решением.

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

    В конце выскажу свою мысль. Пассивные люди не добьются успеха в долине. Долина кипит жизнью и поощряет тех, кто старается взять от жизни максимум. Тут огромные возможности, но нужно быть активным и уметь пользоваться головой, чтобы использовать их. Поэтому людям с советским менталитетом тут сложно.
  • Умные часы LG G Watch и Samsung Gear Live доступны для предзаказа
    0
    Для Pebble есть watchfaces, которые постоянно считают шаги и отображают их количество (если нужно это делать именно постоянно, иначе — есть приложения). Кроме того, использование Pebble для спорта имеет преимущества: вес, время жизни батареи, неслепнущий экран. Русский язык решается сейчас очень просто, буквально в несколько кликов, с помощью pebblebits.
  • Рабочая среда «Деодар» для Линукс
    0
    Спасибо, клевая штука. Не без недостатков, но лучше, чем другие. Скажите, как вы ее нашли? У меня так и не получилось найти ее в гугле, даже зная название проекта.
  • Тренинг по Scala в JetBrains: как это было
    +1
  • Тренинг по Scala в JetBrains: как это было
    0
    Выскажу свое «фи». Иллюстрация scala-way на примере «быстрой» сортировки просто ужасна. Вы отдаете себе отчет, что в такой реализации на один вызов qsort происходит 4 раза создание и копирование массива? Конечно, это всего лишь пример, и он не обязан быть оптимальным, но зачем учить новичков наступать на самые большие грабли скалы — бездумное использование «красивых» методов, за которыми часто скрыты «лишние» операции.
    На мой взгляд, лучше было бы придумать пример, который демонстрирует красивое рекурсивное решение, с использованием красивых фич скалы, при этом по перформансу не уступает императивному подходу. То есть, tail recursion, O(1) list prepending, List immutability, и т.д. Например, у Мартина Одерски в курсе все примеры были как раз такие.
  • Оптимизируем, оптимизируем и еще раз оптимизируем
    0
    key.setDeliveredDateContent(truncateToHours(byPeriodKey.getContentTimestamp()));
    key.setDeliveredDateAd(truncateToHours(byPeriodKey.getAdTimestamp()));
    

    Знакомые строки :)
  • «Краник», или алгоритм для поиска цифр числа Пи
    0
    длинную арифметику, которую мне реализовывать не очень-то хотелось

    Вы же знаете про BigInteger, не правда ли?
  • Генерация музыки в реальном времени
    0
    Отличная идея! Думаю, даже за деньги будет пользоваться спросом.
  • Весёлые (сосисочные) рефакторинги
    +2
    Автор, отпишитесь, пожалуйста, о статусе тут или сделайте где-нибудь и регулярно обновляйте страничку. То, что вас уже месяц не слышно, выглядит некрасиво.
  • Экспорт Дней рождения из вКонтакте в Google Calendar
    0
    Поиском по «ДР null» и дальше руками или через API. А вообще надо было отдельный календарь создать для дней рождения.
  • Весёлые (сосисочные) рефакторинги
    +3
    Автор, напишите, пожалуйста, текущий статус. Интересно же.
  • Весёлые (сосисочные) рефакторинги
    0
    Ну что, пора тем, кому уже удалось поучаствовать, обмениваться впечатлениями :)

    Мне письмо пришло вчера вечером, сегодня днем отправил назад. Кстати! Письмо имеет очень не дружественный человеку вид (тема вида [X-CY] и аттачмент). Так что будьте внимательны и проверяйте спам.

    По поводу задачи. Во-первых, задача очень простая, нетривиальной логики нет. В той ветки, что досталась мне, была работа с файлами, пропертями, internationalization, logging и немного работы с коллекциями.

    Единственный вопрос, который висел в воздухе все время — в какую сторону двигаться. Смотря на каждый кусок кода, думаешь «является ли это частью исходной задачи или инициатива кого-то, кто рефакторил до меня?». Поскольку правилами этого не описано, думаю, каждому вначале придется выбрать, упрощать программу выкидывая что-то «лишнее», или, наоборот, довешивать еще больше enterprise подходов и технологий. Будет очень смешно, если программа из 20 строчной (без мусора) превратится в монстра со спрингом, мавеном, хибернейтом и 20+ классами.

    В общем, спасибо большое автору, мне понравилось, очень жду результатов и статистики. Очень хочется посмотреть, что было до меня и что будет после меня =)
  • Как я использовал Google Glass: будущее, но с ежемесячными обновлениями (часть 2)
    +5
    Хамелеоны темнеют от UV. В помещениях свет, проходя через оконное стекло, почти целиком теряет UV сотавляющую. То есть, в помещениях хамелеоны не темнеют.
  • Демонстрация интерфейса Project Glass и раздача прототипов
    +1
    Лазерная коррекция подходит для относительно небольших диоптрий. Когда у тебя миопия высокой степени, она, во-первых, не может быть полностью скорректирована, во-вторых сопровождается кучей осложнений, которые являются противопоказаниями к лазерной коррекции.
  • Кроссворд из регулярных выражений
    +1
    А вы наблюдательны. Похоже, я прочитал CMM вместе CCM.
  • Кроссворд из регулярных выражений
    +1
    Я еще вчера решил. Кстати, интересно, как составлялся этот кроссворд, вручную или с помощью программы? Там в процессе решения в каждый момент времени довольно мало букв можно однозначно определить.
  • Eclipse for Java Developers. Навигация и редактирование
    0
    Если вы чего-то не делаете, это свидетельствует скорее о вашей ограниченности, а не о том, что делать это — неправильно. Очень частый пример использования поиска/замены по тексту — это как раз рефакторинг legacy кода. Когда в коде есть куча похожих сущностей и из них надо сделать массив/enum. Или, например, вы пишете какой-то тест и нужно захардкодить какие-то пары expected-actual значений (если их недостаточно много для того, чтобы заводить отдельный файл).
    Это навскидку, а таких примеров очень много.
  • Eclipse for Java Developers. Навигация и редактирование
    0
    Моя старая презентация на эту тему. Пусть полежит здесь.
  • Meteor — Node.js для гуманитариев
    +5
    По-моему, дефис употреблен правильно.
  • Первая игра, которую я просто написал для себя
    +1
    Ха, я тоже писал программу для этой головоломки из «Братьев Пилотов», правда, не игровую, а для поиска решения (тогда не знал алгоритма). Уже не помню, на чем писал, скорее всего, тоже паскаль или QBasic.
  • Заочная олимпиада ФУПМ МФТИ
    0
    Безотносительно задач и их сложности. Очень видно, что задачи писались и оформлялись разными людьми. И после никто не потрудился привести их к какому-то одному стандарту. В половине задач ввод-вывод из файла в файл, в другой половине из stdin в stdout.
    К тому же, при составлении задач очень хорошо бы продумывать удобный формат входных данных, если, конечно, их чтение не является частью задачи. Например, лично для меня не очевидно, как «красиво» и просто прочитать вход для задачи O:
    На вход подаются числа от 1 до 200000000, не более 10000000 штук. Из них различных не более 100000.
    Здесь логично было бы первым числом давать количество чисел N.
  • Генератор энтропии Seeder 1.1 существенно уменьшает лаги на Android-устройствах
    0
    А так?
     i = (i + 1) % MAXI
    
  • Java собеседование. Коллекции
    0
    Ха, хитрó. Спасибо.
  • Java собеседование. Коллекции
    0
    Мое решение требует еще O(n) дополнительной памяти.