I needed to do some work with splunk the log and monitoring analytics toolkit. Specifically I needed to combine disparate logs from different systems to solve a problem that had been intefering with our systems for a long time. I had a look around for stuff on the CPAN, but it was either embedded into other bigger things that I didn't want to have to deal with, or did not work for me for maintenance reasons. So I decided to write my own. The library I wrote is available here in draft form.
Now because this was written by me for debugging purposes, I think it shouldn't be a CPAN module - not without a lot of hardening it up - but I wanted to share it anyway, as a handy way of doing API integration.
So To carry on from my last short post another short post. I am going to expand and modify my 20_dad_load.t again this time digging a little deeper in Moose's MOP or to give its full name 'Meta-Object Protocol'
One of the things I like most about moose is how easy it is to do “Introspection” or I like to say 'Lets have a look under the hood'. So I have expanded my role test from the other
day
to this
Are we a support group for disenfranchised Perl developers or advocacy group for all developers? If we want people to join our community then we need to reach out and do some good in theirs.
Do you want to get latest Perl information? If you get newer Perl information, you can know the information faster than others.
I'm Yuki Kimoto. I'm Japanese Perl programmer. I have twitter account. Until now I only tweet newer perl information using Japanese. but from know I tweet using Both Japanese and English.
I tell you what I find, what I think it is good about Perl(perl core feature, web application, cpan module), and my perl product release such as GitPrep.
I'm sharing many topics from now. I add simple description from my experience of professional Perl programmer. If you follow my twitter account, I can tell you good Perl information.
I've been programming in Perl 5 since 2001 or so. In 2012, I took a brief look at Perl 6 just to see what it was all about, and wrote a simple blog entry describing some of the basic changes between P5 and P6. I promptly walked away from the language until a week ago.
Over the course of the last week, I decided that I want to go full-out and really learn the language. My goal was to port my File::Edit::Portable P5 module to P6. This module saves record separators from a file, then when writing back, it re-uses the saved line endings. So if you open a Windows file on a Unix system, it'll re-write the file with the original Windows line endings.
I my last post I did create a Test DAD, but then I discovered the problem with doing this is you may spend considerable time just debugging that class to make sure it at least works with any roles it may have to consume and even if you get it to work you may have problems with the roles it is trying to consume.
So I really should test my Database::Accessor::Roles::DAD before I start any load tests,. My basic test I did in a previous post it a good start bur I want to be able to test it before I have says a 100% good DAD. So Moose come to the resque again with MooseX::Test::Role
With this
MooseX
I can test my role without a 100% perfect consuming class as it just stubs in any subs the role may require. So in
20_dad_load.t
I add in
My main activity is GitPrep this year. I plan to add issue system and wiki system. But I'm hangry. I want to do more about Perl.
Python has pypy. This is a static implementation of Python. Perl don't have yet tools like pypy.
In this month, I create only main syntax structure of static perl. OP tree and virtual machine are not yet created.
The purpose is fast compile, fast runtime, fast culculation, parallel, GC.
These are the lack of perl language.
And I also want to implement static perl as XS in order to call static perl library from Perl language.
So in today's Moose pen I am going to stick to the testing tree and have a look at my brand new 20_load_dad.t file in my brand new database-accessor repository
Now in past test
cases
like this, I did a little creative coding and made up a fake test class for SQL and Mongo drivers that where used when I called this
my $fake_dbh = DBI::db->new();
ok(
$address->retrieve( $fake_dbh, $result ) eq
'SELECT street, city, country FROM person AS me',
'SQL correct'
);
Be sure to read Part 1 and Part 2
of this workshop first.
There is black box testing, glass box testing, unit testing, integration testing, functional testing, system testing, end-to-end testing, sanity testing, regression testing, acceptance testing, load testing, stress testing, performance testing, usability testing, and many more types of testing.
I'll leave it for people with thicker glasses to explain all of the
types. Today, we'll write tests that ensure our weather reporting module
works as expected, and as a bonus, you get to pick your own label for what
type of tests these are. Let's dive in!
TDD
TDD (Test-Driven Development) is where you write a bunch of tests
before you write the actual code, ensure they
fail—because code to satisfy them isn't there yet—and then you write code
until the tests succeed. Now you can safely refactor your code or add new
features without worrying you'll break something. Rinse and repeat.
I recently attended #ILookLikeAnEngManager at OSCON 2016, in Austin, Texas.
It really raised my consciousness about sexism in technology. I naively thought that world-culture as a whole was discouraging women from science, engineering, and technology. It literally hadn't occurred to me that the technology industry was pushing back on women.
I was outraged! When I got home and "informed" my wife she calmly, and patiently asked me how I could possibly not know that. It has been a rough path of introspection since then.
So how did I not know?
I'm a man and didn't have any recent exposure to sexism in the workplace ("sexism? that's so 1990's!").
I like working with women.
I naively thought that working for an "equal-opportunity employer" implicitly demands that we be equal-opportunity employees.
The most-competent software developer on my team happens to be a woman, and I have an excellent team.
So today in the Moose-pen I am not going to any coding just another of those little planning review sessions one should take when creating a new system.
So for the two-bit review,
Planned out and amended my basic API
Settled on the basic architecture
Done some PoC programming
Now know where som of the problem area will be.
Have some workable tests
So my next step was to migrate all my code out from the blog repository up on git-hub and into its own git-hub repository which I have done. I also want to set this up the same way I would do a Perl distribution so I stubbed in some of the necessary files namely a README, a Makefile.PL and the GNU license.
Next I had a close look at the present state of the code. I only moved over the code directly related to Database::Accessor name-space, at this point is just the Accessor.pm file and its embedded classes.
Imagine writing 10,000 lines of code and then throwing it all away.
Turns out when the client said "easy to use,"
they meant being able to access the app without a password, but you took it
to mean a "smart" UI that figures out user's setup and stores it together
with their account information. Ouch.
The last largish piece of code where I didn't bother writing design docs
was 948 lines of code and documentation. That doesn't include a couple of
supporting plugins and programs I wrote using it. I had to blow it all
up and re-start from scratch. There weren't any picky clients involved. The
client was me and in the first 10 seconds of using that code in a real program,
I realized it sucked. Don't be like me.
