I live in an extremely remote part of Northern British Columbia, Canada. It is a minimum of an hour to get to the nearest town. We are exceptionally sparsely populated with a vast amount of land right on the second-largest lake in the province.
To that end, we have a wild abundance of wildlife everywhere. Bears, moose, wolves, coyotes, deer etc etc. I set out to set up a series (eight) wildlife cameras using Raspberry Pis (four on my house, the other four each on a separate cabin), all streaming to a central server that I can display on a television set, with all eight camera streams within a single window.
After I accomplished the bulk of that work, I wanted a way to pan and tilt my cameras individually. The tilt part I use a standard servo with the the servo() functionality of the RPi::WiringPi distribution.
I'll be back in Lausanne again this May...my tenth visit to UNIL and my second to EPFL. Both of these prestigious institutions were founded well before my own country became an independent nation (and UNIL actually dates back to 50 years before the first European even set foot on the Australian continent).
To celebrate a decade of visiting lectures at the University, we're going to offer a rare public performance of my classic Fun With Dead Languages presentation. It's many years since I had the chance to give the full two-hour version of this talk and I've been busily updating it for the occasion. The talk is completely free, but we do want people to register in advance if possible so we can schedule a suitable venue for it.
In addition to that event, of course, we'll still be running a full range of classes on technical and presentation topics:
This is a really stupid (and kludgy) Stupid Lucene Trick: how do you search the full text of your document + metadata without the full text? Simple - you create a separate field (call it fulltext, for example), then populate it with the text of all of your other fields. Voilà! You can now search against "fulltext" for all of the text in your Lucene document without having to know whether, for example, "physical" is in the document body, the abstract, or only in the keywords.
Note that fulltext should be created dynamically from the fields for the particular document, rather than from a fixed set of named fields so you maximize the amount of text you can search against.
And yes, you are duplicating the text of the all of the other fields in this field :(.
After looking at some more examples of 'CASE' in SQL I cam across one I have not encountered yet;
SELECT CASE
WHEN Products.Price < 10 THEN 'under 10$'
WHEN (Products.Price >= 10
AND Products.Price <= 30)
OR (Products.Price >= 40
AND Products.Price <=50) THEN '10~30$ or 40~50$'
ELSE 'Over 50$'
END
FROM Products
As you might know I wrote the Perl Maven Tutorial along with most of the 800 other posts on the Perl Maven site during the past 6 years or so.
It became the most frequently read Perl Tutorial and the site is the 4th most visited Perl-related site after cpan.org, perl.org, and perlmonks.org.
I've received many comments on the individual articles that make up the Perl Tutorial. Some required and immediate fix or answer, but many included suggestions that need a lot more work to implement.
There are also a number of missing articles. Some can be seen as comments in the source of the Perl Tutorial page.
It is time to update the tutorial incorporating the comments made on the individual pages,
filling in holes where some topics have not been covered, and making the whole tutorial more like pages of a book.
I need your help in two ways:
Helping with the content (the source can be found on GitHub)
I have a piece of Perl containing manifest constants that have the same value, but which signify different things. In my testing, I wanted to make sure I was getting the right one out of my code. That seems to mean changing code to test it, which is anathema to me.
It occurred to me today that if I held my tongue right I could change the values of the constants without touching the code they were defined in or exported from. Holy aspect-oriented programming, Batman!
The trick is based on the fact that what use constant really does is to define a constant subroutine with an empty prototype. Now, Perl will allow me to redefine a subroutine -- grumpily if use warnings qw{redefine} is in effect, and happily if not. So I thought all I had to do was load the module that exported the constant, hammer its symbol table, and voila!
We are delighted to announce The Swiss Perl Workshop 2018. This year the workshop will be held in Bern at Gewerblich-Industrielle Berufsschule, an industrial vocational school. The workshop will be held in English, although of course other languages are welcome.
The workshop will take place on Friday 7th and Saturday 8th of September 2018 and thanks to the generosity of the school the workshop will be free to attend. As the venue is a technical school we hope to attract students and teachers, so this year's workshop may be an ideal place to promote Perl to those who have not yet heard of or used the language.
Please spread the word, register, submit talks, and come enjoy a perl workshop in Switzerland's historic capital city. You will find more details over the coming weeks added to the official workshop site.
Encode is a well known core module in Perl with support for encoding and decoding text from almost any character encoding you can think of. But it's also an old module with a large amount of historical cruft.
With inspiration from #perl on freenode IRC, Encode::Simple is an attempt to at least improve on its interface and usability issues. Rather than an awkward and unintuitive bitmask and the option of clobbering the input data, Encode::Simple exports straightforward encode and decode functions that simply return the encoded or decoded result or throw an exception. For the cases where you want to allow invalid characters or byte sequences, encode_lax and decode_lax are provided.
Encode itself supports many more operations such as partial, mixed, and in-place encoding or decoding, where its options may make more sense, but these uncommon use cases are not supported by Encode::Simple.
As a final note, if you are working strictly with UTF-8, I suggest avoiding Encode entirely and using the excellent Unicode::UTF8, or the related filehandle layer :utf8_strict, for fast and correct encoding and decoding.
It appears that one of the more common uses for the CASE statement in SQL is in a 'GROUP BY' or at least a good 80% of the tutorials for SQL I have looked at have it as an example so let see how well the present Driver::DBI handles it.
To start I just add this test to the '60_order_by.t' test case;
Somebody once said, that the power of a programming language is not what it lets you do, but what it lets you do easily. Might be Larry himself who said it, not sure, but I heard it at the London Perl Workshop. I started learning Perl from an old second hand book I found in a charity shop a few years ago. I can't say I am any good at it. While previously I could find lots of resources available, these are increasingly harder to find, more outdated, and less able to address modern use cases. Some folk even suggest it is terminal decline. It would be a pity. It is a powerful language, and using it for me has given me a daily discovery for some feature that I didn't know, and exposed me to a large number of clever folk who can bring a different angle to a problem you have struggling with. To my mind it reflects the versatility of a language that has more than one way to to anything.
Recently, I came across a somewhat-frantic comment on StackOverflow that describes a 2017.01 change to the type of return value of .sort:
"you just can't be sure what ~~ returns" Ouch. […] .list the result of a
sort is presumably an appropriate work around. But, still, ouch. I don't know
of a blog post or whatever that explains how P6 approaches changes to the
language; and to roast; and to Rakudo. Perhaps someone will write one that also
explains how this aspect of 2017.01 was conceived, considered and applied;
what was right about the change; what was wrong; etc.
Today, I decided to answer that call to write a blog post and reply to all of the
questions posed in the comment, as well as explain how it's possible that such an "ouch"
change made it in.
Expected--> SELECT CASE WHEN Price < ? THEN ? WHEN Price >= ? AND Price <= ? THEN ? WHEN Price > ? AND Price <= ? THEN ? ELSE ? END AS price_group FROM Products
Generated-> SELECT CASE WHEN Price < ? THEN ? WHEN Price >= ?andPrice <= ? THEN ? WHEN Price > ?andPrice <= ? THEN ? ELSE ? END price_group FROM Products
In the above I see at least fourt problems;
No space between my 'AND' conditionals
The conditional is in lower case it should be coming into the DAD in upper case and
There is no 'AS' between the 'END' and the 'Alias' 'price_group'
The first one should be no problem as this little patch fixes that
So I don't forget this - my expanded version of something our Larry Wall once said:
"Looking at Perl code, it is easy to tell whether you are looking at the ravings of a lunatic. With Java, you can be several weeks into the project before you realize that you are dealing with the demented discourse of someone who should be trusted with nothing sharper than a spoon."
