Open-source News

In addition to removing legacy X.Org drivers, deprecating legacy BIOS support, and signing RPM contents another Fedora 37 change proposal submitted this past week is for upgrading against RPM 4.18...

New book teaches readers how to tell data stories with PostgreSQL Joshua Allen Holm Sun, 04/10/2022 - 03:00 Up Register or Login to like.

SQL databases can be daunting but can also be very fun if you know how to use them. The information contained in a database can provide many insights to someone who knows how to properly query and manipulate the data. Practical SQL, 2nd Edition: A Beginner's Guide to Storytelling with Data by Anthony DeBarros teaches readers how to do just that.

More great content Free online course: RHEL technical overview Learn advanced Linux commands Download cheat sheets Find an open source alternative Explore open source resources The content

DeBarros, currently a data editor at the Wall Street Journal, pulls from his practical experience in journalism to teach readers how to tell stories with data. The book consists of an introduction, 20 chapters, and several appendices. The introduction sets the tone for the book, explaining what the book is about and who it is for, and the 20 chapters teach lessons about various database topics. Chapter 1 is the traditional "how to set up your environment" chapter and covers how to install PostgreSQL on Windows, macOS, or Linux (specifically, Ubuntu). The following chapters cover the basics of working with SQL databases, like creating databases and tables, performing basic queries, understanding data types, importing and exporting data, and basic math and stats functions. The chapters then progress to more complex topics like joining tables and extracting, inspecting, and modifying data. By the time the reader reaches the book's midpoint, they should have a solid understanding of how databases work.

The chapters in the second half of the book, starting with chapter 11, explore advanced topics.

• Chapter 11 covers statistical functions.
• Chapter 12 explains how to work with dates and time.
• Chapter 13 teaches advanced query techniques.
• Chapter 14 explores text mining features.
• Chapter 15 looks at analyzing spatial data using PostGIS.
• Chapter 16 explains how to work with JSON data.
• Chapter 17 shows how to use views, functions, and triggers.
• Chapter 18 discusses using PostgreSQL from the command line.
• Chapter 19 covers database maintenance.

The final chapter, Chapter 20: Telling Your Data's Story, shifts away from the practical aspects of chapters one through 19 toward providing advice about telling stories using data. Again, Debarros pulls from his experience as a journalist to offer lessons about the whys, hows, and best practices of doing data journalism or data storytelling. If chapters one through 19 are the tools in the toolbox, chapter 20 is a sample blueprint that will inspire the reader to create their own project.

The exercises

There are SQL files and other supplemental resources for the exercises in each chapter in the book's GitHub Repository, except for chapter 20, which has no activities. The repository also contains a file with solutions for each of the "try it yourself" end-of-chapter exercises.

The exercises throughout the book are all very interesting. While the earliest chapters are understandably basic (there are only so many ways to teach CREATE DATABASE and CREATE TABLE), they provide an excellent foundation for the more advanced topics later in the book. The advanced exercises use real-world data to give verisimilitude to the learning experience. The database of choice for Practical SQL, 2nd Edition is PostgreSQL, but the book makes some mentions of different databases when things might work differently. However, it is very much a PostgreSQL book, so that is something to keep in mind.

Final thoughts

Practical SQL, 2nd Edition is a well-written and informative book that can help someone begin to master SQL. Even more importantly, it is an extremely enjoyable book that will keep the reader engaged with interesting, thought-provoking exercises. Anyone interested in learning the ins and outs of PostgreSQL should consider picking up this book. The book's only drawback is that it is a PostgreSQL book, not a database-agnostic book, so anyone trying to learn MySQL, MariaDB, or some other SQL-based database might want to choose a book that focuses on that particular database. The overall "Guide to Storytelling with Data" lessons are something a moderately experienced MySQL, MariaDB, etc. can apply to their database of choice, but this book is not the ideal first book for learning a non-PostgreSQL database. That one caveat emptor aside, I highly recommend Practical SQL, 2nd Edition to anyone wanting to learn PostgreSQL and how to tell stories with data.

Practical SQL, 2nd Edition: A Beginner's Guide to Storytelling with Data by Anthony DeBarros offers an informative and enjoyable way to learn SQL.

Image by:

Opensource.com

Databases What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. 1 Comment Register or Login to post a comment. madtom1999 | April 12, 2022

Worth noting that PostgreSQL allow Stored Procedure overloading which can make development a nightmare if you are unaware of it.

KDE Frameworks 5.93 Brings Multi-Cursor Support for Text Editor Apps, over 280 Changes  9to5Linux

Anbox a Android compatibility layer for Linux. - Linux & Unix  BleepingComputer

MX Linux 21.1 Released with Linux 5.16 for AHS Edition, Based on Debian GNU/Linux 11.3  9to5Linux

A new release of OpenRazer is available as the community project providing open-source Linux drivers for various Razer devices from their keyboards and mice to headsets and other peripherals from the popular gaming device manufacturer...

How To Find Files in Linux  Tom's Hardware

As of this week with openSUSE's Tumbleweed rolling-release distribution it is using GCC 12's libgcc standard libraries and preparing to shift to GCC 12 as the default compiler once ready...

Older AMD GPUs paired with Intel Alder Lake Platforms is leading to hangs during suspend/resume cycles so a patch is pending for the Linux kernel to disable Active State Power Management (ASPM) in such combinations...

https://www.facebook.com/Thyrolin/ - Linux & Unix  BleepingComputer

At the end of March ROCm 5.1 released with CRIU checkpoint/restore support, continued enabling more ROCm components like MIOpen with RDNA(2) GPU compatibility, and other changes. Meanwhile on Friday the ROCm 5.1.1 release was published...

KDE developer Nate Graham is out with his weekly summary of all the interesting changes to have landed this week for benefiting this open-source desktop environment...

KDE Changes This Week "Overflowing With Positive Visual Changes"  Phoronix

Explaining Git branches with a LEGO analogy Seth Kenlon Sat, 04/09/2022 - 03:00 Up Register or Login to like.

Creating a new branch in a code repository is a pretty common task when working with Git. It's one of the primary mechanisms for keeping unrelated changes separate from one another. It's also very often the main designator for what gets merged into the main branch.

Without branches, everything would either have to be cherrypicked, or else all your work would be merged effectively as a squashed rebase. The problem is, branches inherit the work of the branch from which they're forked, and that can lead to you accidentally pushing commits you never intended to be in your new branch.

The solution is to always fork off of main (except when you mean not to). It's an easy rule to say, but unfortunately it's equally as easy to forget, so it can help to look at the reasoning behind the rule.

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles A branch is not a folder

It's natural to think of a Git branch as a folder.

It's not.

When you create a branch, you're not creating a clean environment, even though it might seem like you are. A branch inherits all of the data that its parent contains. If the parent branch is the main branch, then your new branch contains the common history of your project. But if the parent branch is another branch off of main, then your new branch contains the history in main plus the history of the other branch. I often think in terms of LEGO bricks, so here's a visual example that isn't one of those complex Git node graphs (but actually is, secretly).

Say your main branch is a LEGO plate.

Image by:

(Seth Kenlon CC BY-SA 4.0)
​

When you create a branch off of main, you add a brick. Suppose you add a branch called blue.

Image by:

(Seth Kenlon BY-SA 4.0)

The blue branch contains the history of the base plate plus whatever work you do on blue. In code, this is what's happened so far:

$ git branch
* main
$ git checkout -b blueBranch of a branch

If you create yet another branch while you're still in your blue branch, then you're building on top of main as well as blue. Suppose you create a branch called red because you want to start building out a new feature.

Image by:

(Seth Kenlon CC BY-SA 4.0)

There's nothing inherently wrong with this, as long as you understand that your red branch is built on top of blue. All the work you did in the blue branch also exists in red. As long as you didn't want red to be a fresh start containing only the history of your main branch, this is a perfectly acceptable method of building your repo. Be aware, though, that the project owner isn't able to, for instance, accept the red changes without also accepting a bunch of blue changes, at least not without going to a lot of trouble.

Clean break

If what you actually want to do is to develop blue and red as separate features so that the project owner can choose to merge one and not the other, then you need the two branches to both be based only on main. It's easy to do that. You just checkout the main branch first, and then create your new branch from there.

$ git branch
* blue
main
$ git checkout main
$ git checkout -b red

Here's what that looks like in LEGO:

Image by:

(Seth Kenlon CC BY-SA 4.0)

Now you can deliver just blue to the project owner, or just red, or both, and the project owner can decide what to attach to main on the official repository. Better still, both blue and red can be developed separately going forward. Even if you finish blue and it gets merged into main, once the developer of red merges in changes from main then what was blue becomes available to new red development.

Image by:

(Seth Kenlon CC BY-SA 4.0)

Branch example

Here's a simple demonstration of this principle. First, create a Git repository with a main branch:

$ mkdir example
$ cd example
$ git init -b main

Populate your nascent project with an example file:

$ echo "Hello world" > example.txt
$ git add example.txt
$ git commit -m 'Initial commit'

Then checkout a branch called blue and make a silly commit that you don't want to keep:

$ git checkout -b blue
$ fortune > example.txt
$ git add example.txt
$ git commit -m 'Unwisely wrote over the contents of example.txt'

Take a look at the log:

$ git log --oneline
ba9915d Unwisely wrote over the contents of example.txt
55d4811 Initial commit

First, assume you're happy to continue developing on top of blue. Create a branch called red:

$ git checkout -b red

Take a look at the log:

$ git log --oneline
ba9915d Unwisely wrote over the contents of example.txt
55d4811 Initial commit

Your new red branch, and anything you develop in red, contains the commit you made in blue. If that's what you want, then you may proceed with development. However, if you intended to make a fresh start, then you need to create red off of main instead.

Now checkout your main branch:

$ git checkout main

Take a look at the log:

$ git log --oneline
55d4811 Initial commit

Looks good so far. The blue branch is isolated from main, so it's a clean base from which to branch in a different direction. Time to reset the demo. Because you haven't done anything on red yet, you can safely delete it. Were this happening in real life and you'd started developing on red, then you'd have to cherrypick your changes from red into a new branch.

This is just a demo, though, so it's safe to delete red:

$ git branch -D red

Now create a new branch called red. This version of red is intended as a fresh start, distinct from blue.

$ git checkout -b red
$ git log --oneline
55d4811 Initial commit

Try making a new commit:

$ echo "hello world" >> example.txt
$ git add example.txt
$ git commit -m 'A new direction'

Look at the log:

$ git checkout -b red
$ git log --oneline
de834ff A new direction
55d4811 Initial commit

Take one last look at blue:

$ git checkout blue
$ git log --oneline
ba9915d Unwisely wrote over the contents of example.txt
55d4811 Initial commit

The red branch has a history all its own.

The blue has a history all its own.

Two distinct branches, both based on main.

Fork with care

Like many Git users, I find it easier to keep track of my current branch by using a Git-aware prompt. After reading Moshe Zadka's article on it, I've been using Starship.rs and I've found it to be very helpful, especially when making lots of updates to a packaging project that requires all merge requests to contain just one commit on exactly one branch.

With hundreds of updates being made across 20 or more participants, the only way to manage this is to checkout main often, pull, and create a new branch. Starship reminds me instantly of my current branch and the state of that branch.

Whether you fork a new branch off of the main branch or off of another branch depends on what you're trying to achieve. The important thing is that you understand that it matters where you create a branch. Be mindful of your current branch.

Use this helpful LEGO analogy to understand why it matters where you branch in Git.

Image by: Image credits: CC BY-SA 4.0 Klaatu Einzelgänger Git What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. 2 Comments Register or Login to post a comment. Image by:

opensource.com

Victorhck | April 11, 2022

Was brilliant to use Lego for example!
Thanks!

BTW: The link to starship article is wrong and gives a 404 error. It's this one:

https://opensource.com/article/22/2/customize-prompt-starship

Greetings!

Image by:

Opensource.com

AmyJune Hineline | April 12, 2022

Thanks for the comment! I updated the link.

In reply to Was brilliant to use Lego… by Victorhck

10 Best Indie RPG Games for Linux in 2022  It's FOSS

Hackers Exploiting Spring4Shell Vulnerability to Deploy Mirai Botnet Malware  The Hacker News

Hackers Exploiting Spring4Shell Vulnerability to Deploy Mirai Botnet Malware  The Hacker News

Firefox 99 Brings These Two Changes for Linux Users  It's FOSS News

Firefox 99 Brings These Two Changes for Linux Users  It's FOSS News

How to Launch an Amazon Linux EC2 Instance Using Terraform  Security Boulevard