Posts tagged: PostgreSQL

How to build a PostgreSQL-backed website. Quickly.

Model-View-Controller using Ruby-on-Rails & PostgreSQL

So you want to build a website? Quickly! But able to grow to arbitrary size, if fortune smiles.

I’ve been working on just such a website, one which runs the manufacturing process for a world class optical switch manufacturer. They started in 2005 and are now the 2nd leading producer of optical switches. So zero to hero. They started with Ruby-on-Rails & are still running the original code. With a few hacks of course, many of which I built.

So, time for a talk on how to do this. The 2021 PostgreSQL Conference Webinars in the person of Lindsay Hooper was kind enough to extend an invite & I put something short together. I gave the talk earlier today as a webinar. Very happy with the way it came out; it provides a short introduction to how to get started on this, from the database perspective:

I show how to get started building a PostgreSQL-backed website using Ruby-on-Rails, what is meant by the Model-View-Controller architecture, why we want to use that, what tools you need to get started; how to work with the online tutorials; what kind of workflow to use, and which tasks to let Ruby-on-Rails handle versus which are better done by PostgreSQL.

The conference will be posting the video of the webinar in a few days. Meanwhile, I have exported the slides as a PDF up on slideshare.

And if you are wondering what the illo has to do with the talk, it’s a breakdown of the pieces of the Model-View-Controller architecture as it applies to Ruby-on-Rails/PostgreSQL. If you are going to do this, it is the map which is your world.

The Elephant Versus the Bug

Debugging with PostgreSQL -- the Elephant takes on the Bug

Depending on the project, debugging can take 50 to 90% of development time. But it usually gets less than 10% of the press. PostgreSQL has great tools for debugging, but they are most effective when deployed as part of an overall strategy.

Ten days from now I’m doing a webinar on how best to do this. That’s 1pm, July 29th, 2020. You can register here.

It’s a fun talk: I focus on the key ideas, give a few good examples, have a quick quiz “There are three bugs on this slide: you have the next two slides to find them!” and then finish with some of my favorite debugging references: selected as particularly readable & practical.

[Update: the talk was given as planned. Thanks to Lindsay Hooper for great support! Video is online. And the audience of invisible Zoomers upped the number of bugs on the quiz slide from three to five!]

Last time I did this talk, my favorite piece of feedback was from Bruce Momjian, a founder of PostgreSQL and a member of the core team: Bruce said there was stuff he knew but hadn’t heard put into words, and stuff he just hadn’t seen yet.

And that’s how I hope this will be for you!

We will look at strategies for debugging PostgreSQL: how to find bugs, how to fix them, and how to keep them from happening in the first place.

We’ll look at root causes, technical tricks, and scientific strategies, and why — even if you can’t always write perfect code — it is usually a good idea to try.

We’ll hear from Bjarne Stroustrup, Sherlock Holmes, Kernighan and Ritchie, Pogo, & the experts of the PostgreSQL community.

Goal: less time debugging, more time building great tools and apps that stay up & get the job done.

If you can’t wait or just can’t make it, I have the latest version here: PDF, KeyNote, and PowerPoint, name your poison.

Update

Talk went off smoothly, about 65 or 70 attendees. The invisible Zoomers found two more bugs on the “quiz” slide! The event organizer, Lindsay Hooper of the PostgreSQL conference, did a great job setting every thing up, watching over a dry run, and giving feedback during. And she recorded and edited the webinar, so if you are interested in see the video “live”, herewith.

Debugging with PostgreSQL – A Strategic (& Streamlined) Approach

Most popular slide at the talk: and the audience got all of them! (not counting the bit about the official name of Bangkok)

As planned, I gave a talk on Debugging with PostgreSQL at the Philly PostgreSQL conference at Wharton this last Friday (7/19/2019).

Went well: debugging is a great subject & I definitely struck a nerve with the audience; after the talk people were saying they knew about some of the points — which gave them some confidence — and others were new — which gave them some tools. Good.

My most popular slide was a quiz: only 10 lines of code — and from the PostgreSQL man page on foreign keys — but still three bugs. For the record, they are:

  • All of the data types should be domains, not physical types, so the city type should be something like “city_t”, defined as varchar(80). And the temperature should be, say, “fahrenheit_t” (or “celsius_t”), so you know what the units are.
  • The use of key words, like “date”, for field names is not great technique. It is ambiguous at best; breaks stuff at worst.
  • And the width for the city is way too small. Consider the name of Bangkok in Thai, the language of Bangkok: Krungthepmahanakhon Amonrattanakosin Mahintharayutthaya Mahadilokphop Noppharatratchathaniburirom Udomratchaniwetmahasathan Amonphimanawatansathit Sakkathattiyawitsanukamprasit. 177 characters! If you make the city’s type a domain, then you can revise the domain to be, say, “text” — and automagically get the type fixed everywhere you have a city reference.

I was scheduled to go late morning but went first because the opening speaker was still at his hotel. As a result I had the pleasant experience of hearing several later speakers refer to points made in my talk. The most popular was the phrase “lie consistently“.

I had built a form to collect Social Security numbers when I was at Bellcore (now Telcordia). It blew up when one fellow put in a variety of SSNs. I asked him what was going on. He said “I don’t want Bellcore to have my SSN. They have no legal right to it!”. “Fine by me, but just do me a favor & lie consistently“. We both left happy.

I did a run thru of the talk Sunday with my OTC (Official Talk Consultant); she pointed out, with her usual correctness, that I had tried to fit an entire software engineering course into 50 minutes. As a result, the early mornings & late evenings Monday thru Wednesday were spent reorganizing & rewriting. A 2nd run thru Wednesday evening went much better. OTC approved.

But when I did a final final talk & schedule check Friday morning I found the time blocks were now down to 40 minutes. Snip, snip, cut, cut, squeeze, squeeze. I cut out everything that wasn’t on message, useful, & fun. Definitely improved the talk. That which does not destroy us makes us strong. Or at least succinct.

Final version of the talk (PDF): Debugging with PostgreSQL — A Strategic (& Streamlined!) Approach.

Debugging with PostgreSQL – A Strategic Approach

The PostgreSQL Elephant attacks a bug
Debugging with PostgreSQL – A Strategic Approach

The Philly PostgreSQL Meetup is holding an all day conference at the Wharton School in Philadelphia, July 19th, 2019. I will be giving my talk Debugging with PostgreSQL – A Strategic Approach at 11am.

Description:

Depending on the project, debugging can take 50 to 90% of development time. But it usually gets less than 10% of the press. PostgreSQL has great tools for debugging, but they are most effective when deployed as part of an overall strategy.

We will look at strategies for debugging PostgreSQL: how to find bugs, how to fix them, and how to keep them from happening in the first place.

We’ll look at root causes, technical tricks, and scientific strategies, and why — even if you can’t always write perfect code — it is usually a good idea to try.

We’ll hear from Bjarne Stroustrup, Sherlock Holmes, Kernighan and Ritchie, Pogo, & the experts of the PostgreSQL community.

Goal: less time debugging, more time building great tools and apps that stay up & get the job done.

Comments:

I’ll be doing this talk at FOSSCON 2019 as well. That will be Saturday August 17th, 2019.

While I’ve definitely built this for PostgreSQL, it turns out that most of the debugging advice is applicable not just to PostgreSQL but to database in general, and not just to databases, but to most programming langauges.

WordPress Themes