Лучшие практики для подписания блоков с несколькими проектами и разработчиками

Вероятно, что Вы перепутываете синхронный с последовательный .

тело функции в erlang обрабатывается последовательно. Таким образом, то, что Spencer сказал об этом "автоволшебном эффекте", не сохраняется для erlang. Вы могли смоделировать это поведение с erlang все же.

, Например, Вы могли породить процесс, который вычисляет количество слов в строке. Поскольку у нас есть несколько строк, мы порождаем один такой процесс для каждой строки и получаем ответы для вычисления суммы от него.

Тот путь, мы порождаем процессы, которые делают "тяжелые" вычисления (использующий дополнительные ядра при наличии), и позже мы собираем результаты.

-module(countwords).
-export([count_words_in_lines/1]).

count_words_in_lines(Lines) ->
    % For each line in lines run spawn_summarizer with the process id (pid)
    % and a line to work on as arguments.
    % This is a list comprehension and spawn_summarizer will return the pid
    % of the process that was created. So the variable Pids will hold a list
    % of process ids.
    Pids = [spawn_summarizer(self(), Line) || Line <- Lines], 
    % For each pid receive the answer. This will happen in the same order in
    % which the processes were created, because we saved [pid1, pid2, ...] in
    % the variable Pids and now we consume this list.
    Results = [receive_result(Pid) || Pid <- Pids],
    % Sum up the results.
    WordCount = lists:sum(Results),
    io:format("We've got ~p words, Sir!~n", [WordCount]).

spawn_summarizer(S, Line) ->
    % Create a anonymous function and save it in the variable F.
    F = fun() ->
        % Split line into words.
        ListOfWords = string:tokens(Line, " "),
        Length = length(ListOfWords),
        io:format("process ~p calculated ~p words~n", [self(), Length]),
        % Send a tuple containing our pid and Length to S.
        S ! {self(), Length}
    end,
    % There is no return in erlang, instead the last value in a function is
    % returned implicitly.
    % Spawn the anonymous function and return the pid of the new process.
    spawn(F).

% The Variable Pid gets bound in the function head.
% In erlang, you can only assign to a variable once.
receive_result(Pid) ->
    receive
        % Pattern-matching: the block behind "->" will execute only if we receive
        % a tuple that matches the one below. The variable Pid is already bound,
        % so we are waiting here for the answer of a specific process.
        % N is unbound so we accept any value.
        {Pid, N} ->
            io:format("Received \"~p\" from process ~p~n", [N, Pid]),
            N
    end.

И это - то, на что похоже, когда мы выполняем это в оболочке:

Eshell V5.6.5  (abort with ^G)
1> Lines = ["This is a string of text", "and this is another", "and yet another", "it's getting boring now"].
["This is a string of text","and this is another",
 "and yet another","it's getting boring now"]
2> c(countwords).
{ok,countwords}
3> countwords:count_words_in_lines(Lines).
process <0.39.0> calculated 6 words
process <0.40.0> calculated 4 words
process <0.41.0> calculated 3 words
process <0.42.0> calculated 4 words
Received "6" from process <0.39.0>
Received "4" from process <0.40.0>
Received "3" from process <0.41.0>
Received "4" from process <0.42.0>
We've got 17 words, Sir!
ok
4> 
16
задан Daniel Mann 18 February 2016 в 15:25
поделиться

2 ответа

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

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

Единственный недостаток, который я вижу, заключается в том, что наличие ключевого файла, доступного вашим разработчикам, означает, что он не настолько приватен, как должен быть. В идеале, как можно меньше людей (например, только процесс сборки) должны иметь доступ / знать пароль.

Подход с использованием одного файла позволяет упростить управление ключами (есть только один), сохраняя при этом преимущества строгого именования .

13
ответ дан 30 November 2019 в 22:17
поделиться

В настоящее время мы используем один и тот же надежный ключ (.SNK) для каждого проекта в нашем решении. В зависимости от вашего проекта вы можете использовать разные ключи для каждого проекта.

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

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

6
ответ дан 30 November 2019 в 22:17
поделиться