I found a gentle and an in-depth article about OptionParser. Neither quite matched my specific use case of pattern matching options at the function level.
The key is converting the opts
keyword list into a map.
I found a gentle and an in-depth article about OptionParser. Neither quite matched my specific use case of pattern matching options at the function level.
The key is converting the opts
keyword list into a map.
SimpleCardBrand version 0.3.0 changes the :error reason from a String.t to a tuple: {:atom, String.t}. This allows simple programmatic decision making based off the atom along with detailed error messages. Example:
{:error, {:pan_too_short,"Minimum PAN length is 12, found 10."}}
{:error, {:pan_unknown,"Unknown card brand."}}
{:error, {:pan_too_long, "Maximum PAN length is 19, found 20."}}
Added a (NOT PCI COMPLIANT) command-line interface. Use only with test credit card account numbers.
$ ./simplecardbrand 4111111111111111
PAN: 4111111111111111 -> Brand: visa
SimpleCardBrand is feature complete.
It supports all the card brands documented on Wikipedia as of 2023-08-06.
[Read More]SimpleCardBrand is feature complete.
It supports all the card brands documented on Wikipedia as of 2023-08-06.
[Read More]Use an Enum function to stream data from a list.
[Read More]I was recently lamenting Elixir’s lack of Pytest-like parameterized testing (or at least my inability to find such).
I’d found several examples including ExUnit.Parameterized, but I could not find a solution that output the actual parameters from among hundreds that caused the failed assert.
Maciej Lukksepp (icejam_@hachyderm.io
) responded that StreamData property testing should solve the problem, and provided a useful starting point.
Created a mix project.
Added guards to card_brand
that check for String and Integer parameters then
moved the single file into a mix project.
Every card brand has its own test file. The tests validate against the information on the Wikipedia page. Each brand is tested for documented prefix and account number length.
As suspected, there were a few lurking bugs which have now been corrected.
[Read More]After adding 16 new card brands, I’m finding the single file is getting slightly more complex than I’d like.
There’s only about 270 lines of code, but it’s difficult to come up with logical arrangement as many brands have multiple ranges in entirely different areas.
[Read More]The first code runs nicely as a Livebook (v0.10.0) page. It recognizes American Express, Discover, Mastercard, and Visa payment card account numbers (PANs).
After being away from Elixir for a few weeks I thought it would take awhile to get back into the functional mindset, but I found it took less than an hour to start writing reasonable (I hope) code.
[Read More]I’ve selected a small Elixir project to write between wrapping up one Python project and starting on the next. The SimpleCardBrand project will return the bank-card type based on the first six digits in the card.
A quick hex.pm search found packages that return more detailed information, but I didn’t find anything that ran without calling a web service.
I like this for a quick project as it can easily be done in a LiveBook and it primarily relies on function parameter pattern matching.
Let’s see where I am in a few days.
[Read More]