Having needed to implement a simple workflow for taking card payments by Stripe and knowing that I need to do the same again soon for a different product set, I have created a module that I think will be useful to other people. Existing modules to connect with Stripe either do not cater for the latest security measures of 3D card payments in Europe or are a wrapper for the Stripe API. Both of which are, of course useful. But I wanted to create something easy to use that can be used for the typical simple workflow required by many small businesses.

This gives a simple workflow of adding products to a 'Trolley' and then sending the user directly to the Stripe hosted checkout. From there, Stripe returns to either a success URL if payment was taken successfully or a cancel URL if, for any reason, the transaction failed.

Could you please provide me with some feedback regarding both the code and the POD ahead of uploading it to CPAN?

I was thinking Business::Stripe::Simple as the module name - is that sensible?

Note - at the moment, the examples in the documentation have not been tested. They will be before uploading!

Thank you to the Monks who have helped me develop the skills to get the module this far and to the ones who will give useful feedback.
It is very much appreciated.

UPDATE:
I have run the code through Perl::Critic and it passes at 'stern' but generates warnings at 'harsh'. One thing it has found are tab characters instead of spaces despite changing my editor to use spaces after this discussion. I will take out the tabs that have crept in from copying and pasting a few bits of code.

On the suggestion of Critic, I have moved the declaration of $VERSION to after use strict;. Although I thought that had to be first for the CPAN toolchain?

Recently, P5P is arguing about the future development of Perl. As a long-term user of Perl (but not a core developer), I also have some ideas of my own.

The first and most important question is, what are Perl's real capabilities / advantages? sigil？ Regexp? On some degree, yes, but not exactly. Perl's real power lies in its expressiv power and self-evolvement. Language is language, and computer language is also a kind of language (although many people don't realize it now). The purpose of language is to communicate and express what they want to express. At the beginning of Perl language, Larry learned from many excellent functions of the language, so it can let people express what they want quickly accurently, which is the real reason why Perl stands on the river. So I conclude below by learning history of other languages(including human languages):

1. When the language can't deliver what it wants to deliver quickly, there will be fewer and fewer users stay there, such as COBOL, lisp, Latin (human language), even if they have many bright spots.
2. Without users, the language will die. In history, many languages have died out, they may have many advantages and characteristics, but now these characteristics may exist in other languages, but they themselves have died out.
3. The language needs to quickly implement the features it needs, not whether it is elegant or not. Think about Japanese, Chinese, and even English. In the long history, they constantly learn from other languages to implement some new concepts. These implementation may conflict with their own, but it doesn't matter. As long as they can quickly accurately deliver these new concepts to achieve the purpose of communication, the language will not die. Languages that have been slow to implement new functions for the sake of elegant implementation (or because of lack of manpower) have all died out.

Let's go back and see how Perl should do? In recent years, Perl supporters have said that the advantage of Perl is CPAN (stand on the shoulder of cpan). what does it really mean? It means that Perl also has all the functions and libraries which other languages have(though there is maybe not in Perl itself)

1. More and more modules on cpan are not available, and even many authors give up their own modules because they want to adapt to new changes
2. Because XS and its toolchain are too specific to C language and Perl, it is difficult for people who are not familiar with Perl to develop interface libraries. Think about UV, such a popular library needs people like peavans to maintain.
3. Due to the lack of new functions or new libraries, Perl has fewer new users, such as GUI and parallel programming. This is a vicious cycle. Due to the lack of language functions and the complexity of language level, fewer and fewer people use Perl. Therefore, there are fewer and fewer heavyweight modules in cpan, resulting in fewer and fewer people using Perl. It should be understood that the difficulty of learning the language itself is never the first thing for users, but the function is. As long as you have the features users want, no matter how difficult, they will learn.

To sum up, I suggest that the core developers of Perl should be able to focus on (of course, this is only my personal wish) redesigning and implementing a language layer for communication with other languages. The current XS and its toolchain are too limited to C and obscure which makes it difficult for the user to develop such an interface.

In addition, the layer between languages should not be limited to compiled languages, but also include virtual machine languages and other specifications(consider how many ppl on windows use Win32::OlE). Because we are short of developers, when a new popular application or library appears in other languages, it may be difficult for us to have the corresponding Perl version very quickly. If there is a convenient way to establish a conversion layer at this time, so that Perl users can stay in the Perl world happily, I think it is great incentive for the use of Perl! FFI:: platypus does very well. I hope it can enter the official package when it's mature. but I also want it could be more ambitious. to introduce more virtual machine languages, including C sharp, node.js , GO, etc. Inline:: XX may also be a direction, but it seems too dulicate to write its parsers for each language.

Of course, in the long run, of course, P5P can slowly polish the Perl language itself, maybe including type system, object system, better regexp, concurrency programming, etc. but it should be noted that language and its new features need to be learned by users. First of all, users should stay in Perl, without users, language and its features can not prove whether they are useful or not.

Hi, folks.

Recently I've found (here in PerlMonks) a link to one of Donald Knuth's great talks: Computer Programming as an Art. Knowing it was Knuth's sutff, I knew it would be worth my time.

One of the (often overlooked) benefits of computer programming is that it can be fun. But Knuth goes beyond that stating that it should be fun and that a program should be beautiful. Fun and beauty add a lot of value to the program and to programming.

Now, at the same time, observing the IT industry as whole, we can see how much the fun and beauty of programming are being overlooked. More and more "magic tools" are making way to sysadmin jobs, and they're focused on people who don't want to program. IT managers often see them as a means "not to depend too much on programmers". It's laughable, but I've seen it a lot.

One example of such tools are the configuration management tools, such as Ansible, Puppet, Chef and similar tools, which take a more declarative approach to systems management. I'm not saying these tools aren't useful (or even that they are necessarily bad), but I feel like they've taken a lot of the fun away from systems management.

This is not to mention GUI-only tools, which are mostly closed-source. Fortunately I've been far from them. But currently at my job, I help maintain some Ansible routines, and sometimes it's a daunting task. I can't remember how many times I had to grep a repository to find out when some variable was being set. If a declarative approach should be friendly, then I must say it has failed in my case, because the repository I work with has grown into a messy beast (I'm sure my co-workers agree).

Yet, I remember once I've put a perl one-line command in a playbook and was critized precisely for this action. I was told it would bring complexity and that other people would have difficulty maintaining perl code. Can you believe it? A one-line! I'd say it's a joke if someone else told me.

Of course, I wouldn't give up on Perl because of that. But it makes me wonder why must we always prove something that exists for decades is worthy a try, while something created a few years ago is promptly accepted. Of course, it's just my point of view, which not necessarily happens everywhere. Other points of view would be much appreciated.

Over on Re: How Xerces validation access http schemas ?, hippo wrote "It's worth noting that the most recent versions of XML::Validate and XML::Xerces are from 15 years ago and may not play so well with modern systems". This immediately reminded me of a recent search for modules to connect with PayPal where I found Business::PayPal::IPN but didn't look any further than the date which is AUG 19, 2003.

Clearly for things that connect to frequently evolving APIs, being quite up to date is pretty important unless the API allows use of a particular past version. But for things that don't change much, like XML, the need for recent updates is less apparent. As hippo puts it, they need to "play well with modern systems".

So, when deciding whether to use a module, or anything else for that matter, how old is too old?

Some politely requested ground rules:

• refrain from replying to anyone else (except OP)
• please don't ++ OP, I'm not doing this for XP (-- if you must, that's not the ask)
• upvote replies, this provides information/consensus
• refrain from downvoting sincere replies, even trolls/rants (for real)
• focus on your own perspective (this is not currently a debate or zero sum game)
• feel free to post anonymously
• post only once, feel free to edit/update your node as much as you want

Okay, so why am I doing this? For the children. (Seriously, I have a follow up about "the future"; but be patient). I'll probably give that in a few weeks. TIA

Esteemed Monks,

For all past time we have connected directly to our CRM from the scripts that need to read or write the data. It has been my intention for a very long time to create some standard subroutines in a require file to do all the things we regularly need to do. Thanks to The Monastery, I now know I need to use a module to do this. So I have set about creating a suitable module. I also thought this would be a good opportunity to do it properly and include some POD. This module will never be used outside of our use case but it seems like good practice to include documentation.

Could you please look over the code and documentation and for me before I go too much further and advise if I am making any horrible mistakes, what I can improve and how clear the documentation is...

I have pulled out anything that could pose a security threat to Bod::Variables. Not just database username and password but also schema name and table names.

The documentation as generated by pod2html is here.

As I was reading some random old thread on "Why is Python so bad?" I came across this comment which I think reflects why I love Perl so much:

Sudhir Sudhir
July 29, 2019
Python is considered bad because it suffocates you to death while being deaf to the prey’s death cries. It falls on you unexpected from the top of a tree and before it swallows you it has to crush your bones and make you a sack of pulp for easier consumption. Very painful. Won’t recommend at all. It’s not venomous, so you have no option of getting hallucinations through the painful experience before death either.

I wonder how much code would break if all of what RFC 4180bis proposes would be blindly implemented by parsers.

I bet there are tons of CSV files out there that are not UTF-8 and/or do not follow BOM correctly or are real binary to start with.

And what about point 8:

A hash sign MAY be used to mark lines that are meant to be commented lines. A commented line can contain any whitespace or visible character until it is terminated by a line break (CR, LF or CRLF). A comment line MAY appear in any line of the file (before or after an OPTIONAL header) but MUST NOT be mistaken with a subsequent line of a multi-line field. Subsequent lines of multi-line fields can start with a hash sign and MUST NOT interpreted as comments. For example: #commentCRLF aaa,bbb,cccCRLF #comment 2CRLF "aaa","this is CRLF

This would require new options in all parsers to reject lines that start with a #.

As Text::CSV_XS already implements/supports all other options, I wonder if there would be enough motivation to add attributes to recognize/skip comments (which would also require a new config variable that contains the comment lead-in (#, // sprint to mind) and if a leading comment string would only be valid if followed by whitespace (probably more things to consider). This would also mean impact on strict as comments (and empty lines) will, per definition, nog have the same number of fields as the rest of the data.

Ideas welcome as usual.

@array = sort { 0.5 <=> rand } @array;
[download]

• The Perl Journal: 22 issues, spring 1996 through fall 2001
• The Perl Review: 18 issues, winter 2004 through spring 2009

my @original = ( 5, 'A' .. 'C', 0, 4 );
my @sorted = sort sort_sub @original;
my @r_sorted = reverse @sorted;

some_sub( $_ ) for \@original, \@sorted, \@r_sorted;
print '-';
[download]

some_sub( [ sort { $_ * sort_sub } @original ] ) for 0, 1, -1;
print '-';
[download]

my @reversed = reverse @original;

some_sub( $_ ) for \@original, \@reversed;
print '-';

some_sub( [ sort { $_ } @original ] ) for 0, 1;
[download]

This is so great, I have to share it here. This guy nails it on the head. (Spring, we're looking at you.)

I suspect a lot of abuse of config files comes from moving logic out of source code for bad reasons. There are good reasons for not hard-coding, say, ports and service endpoints in your source code, because it makes it easier to run the code in different environments. However, there are also bad reasons for taking things out of code. A couple that I have encountered:

Pride in creating a "generic" system that can be configured to do all kinds of new things "without touching the code." Reality check: only one or two programmers understand how to modify the config file, and changes have to go through the same life cycle as a code change, so you haven't gained anything. You've only made it harder to onboard new programmers to the project.

Hope that if certain logic is encoded in config files, then it can never get complicated. Reality check: product requirements do not magically become simpler because of your implementation decisions. The config file will become as expressive as necessary to fulfill the requirements, and the code to translate the config file into runtime behavior will become much more complex than if you had coded the logic directly.

Hope that you can get non-programmers to code review your business logic. Reality check: the DSL you embedded in your config file isn't as "human readable" as you think it is. Also, they're not going to sign up for a Github account and learn how to review a PR so they can do your job for you.

Marketing your product as a "no code" solution. Reality check: none for you; this is great! Your customers, on the other hand, are going to find out that "no code" means "coding in something that was never meant to be a programming language."

Years ago I posted at Devel::Trace - TODOs done, trace per package some enhancements for Devel::Trace by Dominus. A few days ago I stumbled over the fact that Dominus added me as maintainer on PAUSE. Oh my, oh my... what to do? what to do?

So I decided to make a new release. Features - you can:

• make it behave just like 0.12 with argument "s" to import: perl -d:Trace=s scriptfile
• limit trace to namespaces: perl -d:Trace=Foo::Bar,Baz,Quux scriptfile
  You have to add "main" also to trace scriptfile
• limit trace to subroutines: perl -d:Trace=Foo=sub1:someothersub scriptfile
• limit trace by line numbers and number ranges: perl -d:Trace=20-42:123..321,Foo=17-21
  This limits trace in "main" to lines 20 through 42 and 123 through 321 (you may use "-" and ".." for ranges) and to lines 17 through 21 in package Foo
• trace the codepath stemming from limited traced lines: perl -d:Trace=20..42+:123-321
  Lines 123 - 321 are traced in main but not calls, whereas the entire codepath in lines 20 - 42 is followed
• exclude packages from trace in the open codepath: perl -d:Trace=42-127+:somesub,Net::LDAP=0
  Codepath in lines 42 - 127 is followed as well as calls to "somesub" in main, excluding code in Net::LDAP
• provide other filehandles to trace to (which comprises tracing to a variable) by assigning an open filehandle to Devel::Trace::FH
• provide an alternative format for trace output by assinging a sprintf format to Devel::Trace::FORMAT
• use a formatting function by assigning a function reference to Devel::Trace::FORMAT
  An ugly example is shown below

Now it is possible to narrow down tracing to just the interesting parts of a program without touching the source. It is not fully tested and possibly has bugs. I'd be happy if you'd like to play with it and comment. Bug reports, critics, suggestions for improvement, code review etc are most welcome. Have fun!

update:
- changed the "simple" handling
- removed useless code from yDebug.pm

The 4 pieces represent the "robots" Blue, Yellow, Red and Green on a board with 16x16 cells and some walls.

Rules: Each round one of the robots can be moved horizontally or vertically, and does not stop until it reaches an obstacle - either a wall or another robot.

E.G. in this example the Yellow on B14 can only reach A14 or B16 in one move, and nothing in between. You can only move one robot per round.

The object of the game is to bring one specific robot to an indicated target (here C9 marked with * ) using as few moves as possible.

(Since the goal has no neighboring wall you'll need to position other robots as obstacles nearby to reach it)

    A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P
   --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
 1|                   |                 R |                       |1
      .   .---.   .   .   .   .   .   .   .   .   .   .   .---.   .
 2|       |                                               |       |2
      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .
 3|                                           |                   |3
      .   .   .   .   .   .   .   .   .   .   .---.   .   .   .   .
 4|                       |                                       |4
      .   .   .   .   .   .---.   .   .   .   .   .   .   .   .---.
 5|                                                               |5
   ---.   .   .   .---.   .   .   .   .   .   .   .   .   .   .   .
 6|                   |                                           |6
      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .
 7|       |                                               |       |7
      .---.   .   .   .   .   .---.---.   .---.   .   .---.   .   .
 8|                           |       |       |                   |8
      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .
 9|         *                 |       |                           |9
      .   .   .   .   .   .   .---.---.   .   .   .---.   .   .   .
10|               |                                 B |           |10
      .   .   .   .---.   .---.   .   .   .   .   .   .   .   .---.
11|                       |                                       |11
   ---.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .
12|                                                               |12
      .   .   .   .   .   .   .---.   .---.   .   .   .   .   .   .
13|                               |   |                           |13
      .---.   .   .   .   .   .   .   .   .   .   .   .   .   .   .
14|    (Y)|                                               |       |14
      .   .   .   .   .   .   .   .   .   .   .   .   .   .---.   .
15|               |                               |               |15
      .   .   .---.   .   .   .   .   .   .   .---.   .   .   .   .
16|                   | G                                 |       |16
   --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P
[download]

Question:

• Whats the shortest solution (in number of rounds) to bring Yellow on target? Please display the moves for each round at the end.

Bonus question:

If you are still bored...

• How many rounds do you need at most to reach any field?
• How many rounds to you need if the goal has to be reached by any of the robots, like the Blue?

Careful

I do have a script I wrote 16 years ago.

It needed over an hour back than and runs today in 1:30 min on my laptop, so it's solvable within the given margin. :)

But it took me two days to write it, and you might run into memory problems.

FUN

I had a lot back then, and learned a lot. Hope you too ... :)

Edits

added some clarifications and links

UPDATE

here the positions of the walls (yes strings as non-strict barewords, this script is old)

@vwalls=(A5,A11,B7,B13,C1,D15,E5,E10,G4,G10,H7,H9,H12,I7,I9,J12,K7,L3,
+L15,M9,N7,O1,O14,P4,P10);  # below cell

@hwalls=(B2,B7,B14,D10,D15,E1,E6,E16,F4,F11,G8,G9,H13,I8,I9,I13,J1,K3,
+K8,L15,M10,N2,N7,N14,N16); # to the right 

$Target="C9";
$Y="B14";
$R="J1";
$G="F16";
$B="M10";
[download]

UPDATE

It's specifically requested to bring Yellow on target, the first version was misleading, sorry.

https://www.youtube.com/watch?v=krB0enBeSiE