eskil
Joined 16 years ago
Karma
28
Submissions
13
Member since
May 18
Joined 16 years ago
But the problem would still be the extremely long day. Ending with them having to drive a bus at the end of the shift, utterly exhausted.
The proposed refactor in the article doesn't look like idiomatic erlang to me. How would you refactor the code in the article?
I'd do something like this;
validate(_DbConn, {error, Reason}) ->
{error, Reason};
validate(DbConn, #req{body = ReqJsonStr}) ->
validate(DbConn, json:decode(ReqJsonStr));
validate(DbConn, {ok, #login_request{username = Username, password = Password}}) ->
validate(DbConn, {hash_password(Password), db:find_user(DbConn, Username)});
validate(_DbConn, {HashedPassword, {ok, #user_details{username = Username, hashed_password = HashedPassword}}}) ->
% Hashed password matches the found user record hashed password
% by the power of function pattern matching.
{ok, "hello " ++ Username};
validate(_DbConn, {_HashedPassword, _UserLookupResult}) ->
% Hashed password did not match or user not found.
{error, "wrong name or password"}.
Splitting into exported and "private" functions in module would leave a less messy api. This simply removes the case usage, coupling, highlights function pattern matching and makes for easily testable small functions.(but yeah you're right)
"Those who do not know history are doomed to reinvent CORBA_Environment."
(Although there are few new details, such as the aborting if the dtor determines it wasn't checked.)
If you were a pizza, which topping would you have ?
Of course, in a very early startup, that investment might be so small they won't care, and there's a tax implication for the employee you'll want to be aware of.