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;
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.
Welcome to the Perl 6 Hands-On Workshop, or Perl 6 HOW, where instead of
learning about a specific feature or technique of Perl 6, we'll be learning
to build entire programs or modules.
Knowing a bunch of method calls won't make you a good programmer. In fact,
actually writing the code of your program is not where you spend most of
your time. There're requirements, design, documentation, tests, usability
testing, maintenance, bug fixes, distribution of your code, and more.
This Workshop will cover those areas. But by no means should you accept
what you learn as authoritative commandments, but rather as reasoned tips.
It's up to you to think about them and decide whether to adopt them.
Project: "Weatherapp"
In this installment of Perl 6 HOW we'll learn how to build an application
that talks to a Web service using its API (Application Programming Interface).
The app will tell us weather at a location we provide.
Sounds simple enough! Let's jump in!
So today, to start the new year right, I really am going to have a look at Moose coercion which I have been promissing to do since this
post
. So to refresh your memory I had created my
types
role and one type and added it to my accessor like this
has view => (
is => 'rw',
isa => 'View',
);
So what exactly does coercion do for us? Well as I had illustrated in a early post what I want it to do it take an input hash and then create an object from that hash to save us from typing up such unsightly things as
One of my tasks when I'm not working or writing Perl code is to keep the
finances of the Frankfurt Perlmongers e.V. club in order.
Part of this is doing the taxes but a more important part is to pay the
incoming invoices in time and to keep all the receipts for this in order.
As we do most transfers electronically, it was a long-term goal for me to
provide the board with an automated monthly account statement.
Docker is quite popular solution to rapidly spin up developers environments. I have been playing with it and it seems fun for me. The other fun thing I found that Sparrow could be a good solution to build up new docker images.
Here is short example of how it could be. A few lines in Dockerfile and you have a GitPrep server up and running as docker container. Whew!
fREW's article on using it, although the specific setup refers to a previous repository that can still be cloned but it's probably not maintained any more (not reachable from Github's portal, anyway);
Well off track again. So I am not going to do my bit on coercion today after all. If anyone out there was actually downloading my code and running my tests you might see this;
Load of Database/Accessor/DAD/Types.pm failed:
Error=Can't locate Database/Accessor/DAD/Types.pm in @INC (@INC contains: D:\GitHub\DA-blog\lib D:\GitHub\Replay\lib C:/Dwimperl/perl/site/lib C:/Dwimperl/perl/vendor/lib C:/Dwimperl/perl/lib .) at (eval 378) line 2.
Database/Accessor/DAD/Types (Database::Accessor::DAD::Types) may not be an Database Accessor Driver (DAD)!
Currently rakudo.js is at the point where: node rakudo.js --setting=NULL -e 'use nqp; nqp::say "Hello World"'
works but node rakudo.js -e 'say "Hello World"' doesn't.
What's needed for the later is to get rakudo.js (Rakudo compiled to JavaScript) to compile the setting
The general work-flow for that is:
Try to compile the setting with rakudo.js.
While rakudo.js is compiling some error appears.
I then figure out wheter it's a result of a missing feature or some bug in the js backend.
I implement the feature and write tests for it or fix the bug.
I then repeat the process.
Lather, rinse, repeat.
Until the setting compiles Rakudo.js is not yet usable by users.
Even getting something very simple like say "Hello World" requires a fair chunk of the setting to work.
The rakudo specific work is done in the js branch of rakudo https://github.com/rakudo/rakudo/tree/js.
Most of the work on the backend itself is done in the master branch in the nqp repo.
I recently wrote about Veure's test suite and today I'll write a bit about how we manage our database. Sadly, this will be a long post because it's a complicated problem and there's a lot to discuss.
When I first started Veure, I used SQLite to prototype, but it's so incredibly limited that I quickly switched to Postgres. It's been a critically important decision, but I want to take a moment to explain why.
All software effectively has four "phases" which amount to:
Initialization
Input
Calculation
Output
Note that we could rewrite the above as:
Initialization of data
Input of data
Calculation of data
Output of data
Notice a pattern?
Yeah, I thought so. There are all sorts of areas where we could get things wrong in software, but the further down the stack(s) you go, the more care you need to take because the more damaging bugs can be. Data storage is often pretty low in your stack and you don't want to get this wrong. So what happens?
