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'
);
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.
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.
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.
So today I am going to follow along from my last post and come up with a little better way to test my Database::Accessor::Roles::DAD role.
This stems from my mistake of the other day of not addng in the 'Collections' attribute to my “Database::Accessor::Roles::DAD” role. Now the purpose of this Role is to supply all the necessary objects from my Accessor.pm down into the various DADs so it is importat that I pass that along.
So I guess my first test is to check that I have my Role in correct shape. A simple use ok will do that, but what I want is a way to test that all my attributes are present in a DAD. Now this is when the Meta-data part of Moose really comes into its own. All I need to do is;
my @attributes = $address->meta->get_all_attributes;
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.
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.
Today I am d going to start filling in my API a little and some might remember the table from this
post
looking at it a second time I think I need to make a few adjustments to this
+-------------------+-----------------+-----------------+
| Data Accessor | SQL | Mongo |
+-------------------+-----------------+-----------------+
| Param | Param | Param |
| Element | Field | Name Value Pair |
| Predicate | Predicate | Options |
| View | Table (or view) | Collection |
| Condition | Where | Find |
| Link | Join | Lookup |
| Gather | Group | Aggregate |
| Filter | having | ? |
| Sort | Order | Sort |
+-------------------+-----------------+-----------------+
Just so I updated the table to link the 'Condition' to the where clause in SQL and Find in Mongo, and just as a reminder here it is again;
Condition
A logical Predicate supplied to the target database by the Data Accessor to filter data.
Now it makes no sense to have just one condition on a query so this should be a collection of some form so I think I have to redefine this attribute as
Conditions
An Arry-Ref of logical Predicates supplied to the target database by the Data Accessor to filter data.
And in my code I added
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.
DBIx::Class is a great way to hide database interactions in your Perl classes. However, something that you might find easy in normal DBI queries can seem hard in DBIx::Class, because you lack direct access to the SQL. Take for example the following query:
select dayparts.name from eventtyperooms
join slots on (eventtyperooms.room_id=slots.room_id)
join dayparts on (slots.daypart_id = dayparts.id)
where slots.is_reserved=0 and eventtyperooms.eventtype_id='E375219C-CDBB-11E5-8739-AFC57843E904'
group by slots.daypart_id
order by dayparts.start_date asc;
There are lots of joins going on here and not all of them are on primary keys. Plus we’ve got some other qualifiers in there. This is where search_related() can come to the rescue.
Well for today’s post I am going to continue along with one of the basic building blocks of a good Moose program coercion. We saw in the last post how I started to clean up my interface with coercion and I am going to do that to the next
Accessor.pm
attribute
has elements => (
isa => 'ArrayRef',
is => 'rw',
);
[This is a post in my latest long-ass series. You may want to begin at the beginning. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.
IMPORTANT NOTE! When I provide you links to code on GitHub, I’m giving you links to particular commits. This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post. Just be aware that the latest version of the code may be very different.]
Last time I rearranged our UI to be (hopefully) a bit more intuitive. This time I want to clean up the remainder of those pesky CPAN Testers failures on our way to the next solid release.