Pull to refresh
34
0
Send message

(y−x) ∼ x
Видите проблему? Мы сравниваем x с его отрицательной версией.

Это утверждение неверно, от этого все выводы из статьи неверные. Оно было бы верным только при константном у. Если у ~ х^10, то и (y−x) будет ~ х^10 на определенных интервалах.

Иронично, что статья, нацеленная на опровержение эффект Даннинга-Крюгера, подкрепляет его

Очень удивлюсь, если html = null вообще на что-то влияет в примере, т.к. область видимости переменной заканчивается сразу после этой инструкции.

В тарантуле есть multikey индексы — одна запись может быть проиндексирована по нескольким значениям. Документации не могу точной найти, но вот тут что-то есть https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/create_index/#box-space-path-multikey. Судя по примеру, можно указать сразу json-path до поля c несколькими значениями.

Если новый формат спэйса совместим с текущим, то его можно применить при инициализации приложения в space:format(). Например, добавить nullable поле в конец или поменять тип поля на совместимый.


Вторичные индексы можно добавлять так же при инициализации приложения с space::create_index(name, {if_not_exists = true}). Создание индекса не блокирует процесс, т.ч. под нагрузкой должно быть ок. Удалять индексы можно там же с index = space.index[name]; if index then index:drop() end. Вместо изменения индекса можно добавить новый, а старый удалить.

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

На скрине


Coinbase provided the following information

Сделал официальный запрос, получил ответ.

У русской приставки «вы-» с течением времени тоже появились переносные значения. Одно из таких значений — «до конца, полностью». «ВЫ-течь» означает не просто «течь». «ВЫ-течь» означает «вытечь полностью».

А как же "вытекать"? "Полностью" не от приставки зависит, а от суффикса, определяющего совершенный глагол или несовершенный. То же самое с английским leaking out.

А может все проще, и потом окажется, что там LinkedList был. Бинарный поиск получится O(n log n).

    .reduce((result, film) => ({
      ...result,
      [film.id]: film,
    }), {})

Вместо простого алгоритма наполнения хэша со сложностью O(n) получается n наполнений хэша общей сложностью O(n!). Создается n промежуточных объектов. В некоторых случаях это может создать большую нагрузку на GC, т.к. общее количество ключей во всех этих объектах тоже будет n!..
Такое будет работать быстро в функциональных языках, благодаря оптимизациям, которые возможны из-за других особенностей языка. В других языках, включая js, этих оптимизаций может не быть (скорее всего).
Подходы ФП могут сделать код читаемым и лаконичным. Хотя в этом примере страдает даже читаемость.

Ну покажите же, пожалуйста, цифры :)


Искать неточность в доказательстве сложнее, чем замерить производительность. У меня получилась нелинейная зависимость времени от n для вашего алгоритма:


Calculating -------------------------------------
                1000      2.755k (± 3.9%) i/s -     13.860k in   5.038808s
               10000    273.275  (± 2.9%) i/s -      1.378k in   5.046871s
              100000     26.691  (± 3.7%) i/s -    134.000  in   5.027327s
             1000000      2.590  (± 0.0%) i/s -     13.000  in   5.021461s
             2000000      1.309  (± 0.0%) i/s -      7.000  in   5.349981s

Comparison:
                1000:     2755.2 i/s
               10000:      273.3 i/s - 10.08x  slower
              100000:       26.7 i/s - 103.23x  slower
             1000000:        2.6 i/s - 1063.97x  slower
             2000000:        1.3 i/s - 2105.49x  slower

код
# ruby
def fn(n)
  pr = []
  lp = Array.new(n)
  2.upto(n) do |i|
    unless lp[i]
      lp[i] = i
      pr.push i
    end
    pr.each do |p|
      break unless p <= lp[i] && p * i <= n
      lp[p * i] = p
    end
  end
  pr
end

puts fn(100).join(' ')

require 'benchmark/ips'
puts Benchmark.ips { |x|
  [1_000, 10_000, 100_000, 1_000_000, 2_000_000].each do |n|
    x.report(n.to_s) { fn(n) }
  end
  x.compare!
}

Если проблема в языке с GC, или в чем-то еще, покажите, пожалуйста, это вашими измерениями.

В последнем примере по-моему вариант с try-catch получается чище.


fun makeRequest(request: Request): List<ResponseData> {
  val response = httpClient.newCall(request).execute().body()
  ObjectMapper().readValue(response, ParsedResponse::class.java).data
}

fun main(args : Array<String>) {
  try { 
    makeRequest(RequestBody(args)).data.toString()
  } catch (Exception exception) {
    exception.message
  }
}

А как обстоят дела с фильтрацией ошибок по типу? Двухуровневый when?

А сеттер — метод вроде же.

Слайдов не хватало, надо было что-то добавить. В любом нормальном шаблонизаторе есть вывод сырого html.

На середине статьи были мысли примерно такие же. "Открыто новое достижение: 95% функций — чистые!", "в JS нет глобальных моков?!".


Но потом с раздела "Зачем это всё?" автор объясняет, как чистые функции помогают при дебаге. Мне это показалось довольно убедительным и полезным. Если рассуждать дальше, то появляются вопросы по сравнению приложения, написаного на чистых функциях, и приложения, написаного с качественным ООП:


  • насколько дебаг проще?
  • какое сравнение трудозатрат на дальней дистанции?
  • чему проще научить, и какой подход проще внедрить, с учетом того, что в большинстве ЯП нет проверки чистоты функций?
  • что выгоднее для бизнеса?

Arel решает часть проблем, которые вы решаете с помощью quoted_table_name, избавляя при этом от необходимости писать sql:


scope.
  where(arel_table[:some_date].gt(3.days.ago)).
  where(OtherModel.arel_table[:some_number].lteq(smth))

На самом деле, на arel можно написать почти любое выражение sql, но иногда это может оказаться слишком громоздко. И документация оставляет желать лучшего.


Конечно, разные базы данных имеют разный функционал и даже свое надмножество SQL. При этом есть много проектов, которые действительно поддерживают разные СУБД. Например, Redmine. При разработке не публичных приложений будет странно, если команда собирается менять СУБД, при этом использует специфичный функционал. ActiveRecord тут вообще не причем.


По остальным моментам я упустил мысль уже на таймстэмпах — из кода непонятно, какие задачи решает приведенный код. Почему обновлять (updated|created)_at в базе "сильно проще"? touch тоже имеет свой контракт для разработчика, если следовать ему, то все будет работать.

Вы хотите, чтобы я за вас проверил?)

Пример с Fetcher тоже из этой документации. В статью почему-то не добавили совет и пример:


Пишите параметры колбэков, как не-опциональные:
/* OK */
interface Fetcher {
getObject(done: (data: any, elapsedTime: number) => void): void;
}

"… всегда можно передать коллбэк, который принимает меньшее число аргументов" будет правильнее.

Что-то не работает.


class A implements Fetcher {
    getObject(done: IGetObjectCallback) {}
}

const a = new A
a.getObject((x: any, y: number) => {})
// TS2345: Argument of type '(x: any, y: number) => void' is not assignable to parameter of type 'IGetObjectCallback'.

Официальные доки советуют использовать опциональные параметры вместо перегрузок: https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#use-optional-parameters

Посмотрите https://github.com/trailofbits/algo. Может быть, все что нужно будет — перевести ридми.

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

1
23 ...

Information

Rating
Does not participate
Works in
Registered
Activity