This year I’ve hit double digits in my speaker profile (I know, right – how did that happen?! – Ed). And, as with my tech career, I’m always looking for ways to improve my public speaking skills.
The internet is full of advice and suggestions, but I often wonder if they’re valid and trustworthy. I also ask questions of myself. Have I picked up bad habits? Am I practising my own advice?
So when I found out about Speak Effectively At Conferences it seemed like a good investment. After reading it, I want to reflect on my expectations and the insights gained from the book. Before I dive in, let’s take a moment to learn about the author.
The Author
Sheen Brisals is an experienced engineering leader with a career beginning in the early 1990s, including roles at Oracle, Lego and, most recently, Sky. He is an international speaker, an O’Reilly author and an AWS Serverless Hero.
The Book
From the Speak Effectively At Conferences blurb:
Speak Effectively At Conferences…goal is to make everything about speaking at conferences known to you. It aims to familiarize you with the entire process, grow your comfort level, raise your confidence, and transform you into an effective speaker!
Speak Effectively At Conferences is published on Leanpub, a self-publishing platform where authors can release their work in stages and get feedback. It is currently available at a suggested price of $20, with discounts for students and low-income readers.
As of June 2025, Speak Effectively At Conferences is an early-release eBook. I am reviewing version 10 of the book, which was published on 11 April 2025. The book is still undergoing editing and review, and the content will be updated as this process continues. The final release will also include page numbers and an ePub version.
Motivations
This section examines my motivations for buying and reading Speak Effectively At Conferences.
Boost My Knowledge & Skills
So far, I’ve been very fortunate to have access to some great speaking-focused resources, such as:
Speak Effectively At Conferences offered an opportunity to validate skills and learn from an expert. Sheen is renowned for his speaking expertise, and his book provided a great chance to explore his knowledge and insights.
Build My Confidence
Speaking of knowledge and skills, anyone reviewing my speaker profile, community involvement and career history might conclude that I am reasonably confident in using and applying them.
The reality is quite different. While I can claim to be more confident now than I was when I started this mad journey, there’s still much to work on as part of a pursuit that’s essentially endless.
As I connect with more speakers at various events, I’ve noticed that managing confidence and anxiety is a factor at all experience levels. Speakers often enjoy sharing tips with one another, so I was eager to discover what suggestions Speak Effectively At Conferences could provide. Ultimately, it could at least confirm whether others share my current habits and strategies.
Define A Roadmap
Currently, I find myself in an unexpected position as a speaker. On one hand, I can’t really call myself a new speaker anymore as my speaker events list is now in double digits. On the other hand, I don’t feel that I have enough experience to call myself an experienced speaker.
I’m seeking resources to help me advance to the next level (whatever that is). But I find myself struggling to identify what that looks like and entails. What should I measure and develop? What separates my counterproductive habits from my unique selling points?
Ultimately, I don’t know what I don’t know. Well, Sheen does! My hope with Speak Effectively At Conferences was that it would share some of his decades of experience and expertise, and might guide me towards answering some of these questions.
Book Review
In this section, I’ll summarise the various parts of Speak Effectively At Conferences and examine what stood out in each.
Part 1: Your Knowledge
Part 1 of Speak Effectively At Conferences begins before any words are spoken or slide decks are produced. It explores the historical significance of public speaking and its role in supporting basic human instincts like public gathering and group learning. Sheen examines how public speaking fosters knowledge, skills and trust for both the audience and the speaker. Additionally, the section addresses common mental barriers that new speakers may encounter.
Having built up the case for speaking, Sheen examines how to build credibility as a speaker. He explores several approaches to this, offering support and guidance on getting started. Not everyone enjoys writing or can film content, so this broad overview is a valuable addition.
Part 2: The Stage
Part 2 of Speak Effectively At Conferences focuses on the various aspects of the conference ecosystem. Sheen’s expertise is immediately apparent as he divides conferences into four (Four! – Ed) distinct groupings and examines the differences between them. These groupings all make sense – I’d just never thought about conferences in those terms before!
Sheen also explores various speaking venues, both common and uncommon. I can already tick a few off my list, including a warehouse and a cinema. However, I think I’m still a way off speaking in a ballroom!
Part 2 also examines the facilities and technology available to speakers, ranging from audio and visual equipment to private and backstage facilities. These tools vary depending on the venue – for example, don’t expect a teleprompter at a user group event. However, the right tech can make or break a session – something I can personally attest to, having been an attendee, speaker and stage manager (kinda – Ed)! I now have a persistent mistrust of HDMI cables.
Finally, Sheen comments on some of the perks of public speaking. I can imagine he gets asked about this a lot! Some of his experiences match mine – I’ve been invited to two speaker meals so far, although my nerves got the better of me for the first one! This section emphasises the themes of humility and modesty from Part 1 while considering these perks. Ultimately, public speaking isn’t about you; it’s about your audience.
Part 3: Content is King; Context is Queen
Part 3 of Speak Effectively At Conferences focuses on the lifecycle of a session, from creation to rehearsal. It begins with idea generation, curation and development. I use my Second Brain for this, and it appears that Sheen does something similar!
Then there’s a whole chapter dedicated to submitting talks, which is probably the star of the entire book for me. The Call For Paper (CFP) process has a fair amount of mystery attached to it, and rightfully so as the process should be as fair as possible. Sheen has been on both sides of the CFP process – both as applicant and reviewer – and the chapter fully reflects his wealth of experience.
Sheen also discusses how to handle CFP rejections, so don’t approach this chapter expecting hacks or a checklist for success! This is a common experience for most speakers – indeed, my Data Pipelines and Step On It sessions currently have rejection rates of 30% and 40%, respectively. So this is a thoughtful addition.
Part 3 then focuses on designing the talk itself. Sheen discusses essential elements such as the structure, flow and composition of a presentation. He then moves on to exploring slide design choices, offering creative tips and addressing common pitfalls. Part 3 ends by examining the rehearsal process. I personally have strong opinions about rehearsals that are built around another mantra of mine:
“The audience is making time for you, so make time for them.”
So seeing Sheen’s approach is very welcome. It seems we both rehearse in hotels!
It was hard to summarise this part of Speak Effectively At Conferences – there’s loads of great advice that I don’t want to spoil or misrepresent! I already see this part as the one I’ll return to most often. Most of my bookmarks led to pages here, and the advice is credible, informative and relatable.
Part 4: The Delivery
Part 4 of Speak Effectively At Conferences focuses on the act of delivering sessions. It begins by focusing on physical stance, breathing, and vocalisation, followed by exercises for mentality and concentration.
Sheen then turns his attention to preparation. This is an area with many facets, ranging from the technical and personal to the administrative. Drawing on his own experiences, Sheen offers guidance that helps readers identify what is most relevant to their current needs.
Finally, Sheen emphasises the importance of delivering a compelling session by sharing strategies for engaging the audience and improving stage presence. He offers tips for audience interaction, including how to set expectations, a framework for addressing audience questions and, equally importantly, managing off-stage interactions with the audience. This aspect often discourages many individuals from speaking, so it is reassuring to see it included.
Part 5: Life As A Speaker
Part 5 of Speak Effectively At Conferences discusses what happens after the screens go dark and the audience departs. Sheen explores themes of reflection and introspection, focusing on recognising both strengths and areas for improvement. This section also discusses feedback, highlighting what speakers can offer to the organisers and what they can receive from attendees. Learning how to give and receive feedback is an important skill, and it is an area that I need to develop.
To close, Sheen explains how he organises and shares his content. This is essential for both current projects and past materials. A well-structured and reliable warm storage system is easy to navigate, simple to access and share and effective for version control. Additionally, a legacy storage system serves as a valuable and robust knowledge repository, is easy to back up and provides guidance for the development of future content.
Thoughts
In this section, I share my thoughts on the book and how it aligns with my motivations for reading it. As the book is currently subject to change, I may revisit some of these sections in the future as needed.
Structure & Scope
The structure of Speak Effectively At Conferences is logical and well thought out, covering the entire lifecycle of a session from initial development to final retrospective. I found certain chapters particularly interesting, and they were easy to find and complemented the surrounding content. I’ve placed several bookmarks throughout the book that I’m already revisiting now, and will continue to refer to in the coming months and years.
I feel like the book’s title doesn’t do it justice. Speak Effectively At Conferences almost sells the book short, as its advice goes far beyond the conference circuit. People might see this book’s title and think it doesn’t apply to them, but Sheen’s insights are equally valid at meetups, internal presentations and many other social settings. That’s not to say every speaker will benefit from every chapter – some may not aspire to present at re:Invent; others may be content with their idea curation. However, the book’s layout and tone make it easy to find and extract the advice that fits a speaker’s specific needs.
Style & Personality
Sheen’s writing style closely reflects his personality. The book is written in a conversational and approachable manner. Many chapters incorporate Sheen’s real-world experiences, not all of which are positive. This blend of honest and credible advice, alongside an inviting tone, brought many key insights to life for me.
In fact, I found myself mentally reading several sections in his voice. If you’re reading this, Sheen, an audiobook version might be a great idea!
Takeaways & Reflections
Learning about Sheen’s speaking journey has given me valuable perspective and guidance for my own speaking goals. I found myself nodding in agreement in some parts and recognising improvement areas in others.
My main goals as a speaker have always been to improve my communication skills and build my confidence. Speak Effectively At Conferences reaffirms that speaking, like any skill, requires time, practice and a willingness to fail. Sheen’s humility and openness are evident throughout, and his willingness to share his less polished moments with his proud ones makes the book all the more impactful.
Summary
In this post, I reviewed the 2025-04 early release of Sheen Brisals’ self-published 2025 book Speak Effectively At Conferences.
Speak Effectively at Conferences is a valuable resource that offers practical advice for speakers at all levels. Sheen draws on decades of experience to provide practical guidance, whether creating a first presentation or practising a keynote speech. I plan to refer back to it often and am very pleased with my purchase.
Sheen is currently actively working on the book. The final version will be available on Amazon and other booksellers. Follow Sheen’s LinkedIn for the latest developments.
If this post has been useful then the button below has links for contact, socials, projects and sessions:
Data validation is a crucial component of any data project. It ensures that data is accurate, consistent and reliable. It verifies that data meets set criteria and rules to maintain its quality, and stops erroneous or unreliable information from entering downstream systems. I’ve written about it, scripted it and talked about it.
Validation will be a crucial aspect of Project Wolfie. It is an ongoing process that should occur from data ingestion to exposure, and should be automated wherever possible. Thankfully, most data processes within Project Wolfie are (and will be) built using Python, which provides several libraries to simplify data validation. These include Pandera, Great Expectations and the focus of this post – Pydantic (specifically, version 2).
Firstly, I’ll explore the purpose and benefits of Pydantic. Next, I’ll import some iTunes data and use it to explore key Pydantic validation concepts. Finally, I’ll explore how Pydantic handles observability and test its findings. The complete code will be in a GitHub repo.
Let’s begin!
Introducing Pydantic
This section introduces Pydantic and examines some of its benefits.
About Pydantic
Pydantic is an open-source data validation Python library. It uses established Python notation and constructs to define data structures, types and constraints. These can then validate the provided data, generating clear error messages when issues occur.
Pydantic is a widely used tool for managing application settings, validating API requests and responses, and streamlining data transfer between Python objects and formats like JSON. By integrating both existing and custom elements, it offers a powerful and Pythonic method for ensuring data quality and consistency within projects. This makes data handling in Python more reliable and reduces the likelihood of errors through its intuitive definition and validation processes.
Pydantic Benefits
Pydantic’s benefits are thoroughly documented, and the ones I want to highlight here are:
Intuitive: Pydantic’s use of type hints, functions and classes fits well with my current Python skill level, so I can focus on learning Pydantic without also having to explore unfamiliar Python concepts.
Fast: Pydantic’s core validation logic is written in Rust, which enables rapid development, testing, and validation. This speed has contributed towards…
Before I can start using Pydantic, I need some data. This section examines the data I am using and how I prepare it for Pydantic.
iTunes Data
Firstly, let’s extract some data from iTunes. I create iTunes Export files using the iTunes > Export Playlist command. Apple has documented this, but WikiHow’s documentation is more illustrative. The export file type choices are…interesting. The one closest to matching my needs is the txt format, although the files are technically tab-separated files (TSVs).
iTunes Exports contain many metadata columns. I’m not including them all here (after all, this is a Pydantic post not an iTunes one), but I will be using the following subset (using my existing metadata definitions):
Note that the starred Album and Track Number columns have purposes that differ from the column names. The reasons for this are…not ideal.
Track Number contains BPM data as, although iTunes does have a BPM column, it isn’t included in the exports. And the exports can’t be customised! To include BPMs in an export, I had to repurpose an existing column.
Great. But that’s not as bad as…
Album contains musical keys, as iTunes doesn’t even have a key column, despite MP3s having a native Initial Key metadata field! Approaches to dealing with this vary – I chose to use another donor column. I’ll explain Camelot Notations later on.
That’s enough about the iTunes data for now – I’ll go into more detail in future Project Wolfie posts. Now let’s focus on getting this data into memory for Python.
Data Capture
Next, let’s get the iTunes data into memory. Starting with a familiar library…
pandas
I’ll be using pandas to ingest the iTunes data. This is a well-established and widely supported module. It also has its own data validation functions and will assist with issues like handling spaces in column names.
While iTunes files aren’t CSVs, the pandas read_csv function can still read their data into a DataFrame. It needs some help though – the delimiter parameter must be \t to identify the tabs’ delimiting status.
So let’s read the iTunes metadata into memory and…
Python
df = pd.read_csv(csv_path, delimiter='\t')>>UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
Oh. pandas can’t read the file. The error says it’s trying the utf-8 codec, so the export must be using something else. Fortunately, there’s another Python library that can help!
charset_normalizer
charset_normalizer is an open-source encoding detector. It determines the encoding of a file or text and records the result. It’s related to the older chardet library but is faster, has a more permissive MIT license and supports more encodings.
Here, I’m using charset_normalizer.detect in a detect_file_encoding function to detect the export’s codec:
I define a detect_file_encoding function that expects a filepath and returns a string.
detect_file_encoding opens the file, reads the data and stores it as raw_data.
charset_normalizer detects raw_data‘s codec and stores this as detection_result.
detect_file_encoding returns either the successfully detected codec, or the common utf-8 codec if the attempt fails.
I can then pass the export’s filepath to the detect_file_encoding function, capture the results as encoding and pass this as a parameter to pandas.read_csv:
There’s one more action to take before moving on. Some columns contain spaces. This will become a problem as spaces are not allowed in Python identifiers!
As the data is now in a pandas DataFrame, I can use pandas.DataFrame.rename to remove these spaces:
In this section, I tell Pydantic about my data model and the types of data it should expect for validation.
Introducing BaseModel
At the core of Pydantic is the BaseModel class – used for defining data models. Every Pydantic model inherits from it, and by doing so gains features like type enforcement, automatic data parsing and built-in validation.
By subclassing BaseModel, a schema for the data is defined using standard Python type hints. Pydantic uses these hints to validate and convert input data automatically.
Let’s explore BaseModel by creating a new Track class.
Creating A Track Class
Pydantic supports standard library types like string and integer. This reduces Pydantic’s learning curve and simplifies integration into existing Python processes.
Here are the very beginnings of my Track data model. I have a new Track class inheriting from Pydantic’s BaseModel, and a Name field with string data type:
Python
classTrack(BaseModel): Name: str
Next, I add a Year field with integer data type:
Python
classTrack(BaseModel): Name: str Year: int
And so on for each field I want to validate with Pydantic:
Python
classTrack(BaseModel): Name: str Artist: str Album: str Work: str Genre: str TrackNumber: int Year: int MyRating: int Location: str
Now, if any field is missing or has the wrong type, Pydantic will raise a ValidationError. But there’s far more to Pydantic data types than this…
Defining Special Data Types
Where no standards exist or where validation rules are more complex to determine, Pydantic offers further type coverage. These include:
One of my Track fields will immediately benefit from this:
Python
classTrack(BaseModel): Location: str
Currently, my Location field validation is highly permissive. It will accept any string. I can improve this using Pydantic’s FilePath data type:
Python
classTrack(BaseModel): Location: FilePath
Now, Pydantic will check that the given location is a path that exists and links to a valid file. No custom code; no for loops – the FilePath type handles everything for me.
So I now have data type validation in my Pydantic data model. What else can I have?
Pydantic Built-In Validation
This section explores the native data validation features of Pydantic, including field annotation and constraints.
Introducing Field
In Pydantic models, data attributes are typically defined using Python type hints. The Field function enables further customisation like constraints, schema metadata and default values.
While type hints define what kind of data is allowed, Field defines how that data should behave, what happens if it’s missing and how it should be documented. It adds clarity to models and helps Pydantic enforce stricter rules.
Let’s run through some examples.
Custom Schema Metadata
One of the challenges in creating data pipelines is that the data fields can sometimes be unclear or difficult to explain. This can cause confusion and delay when building ETLs, examining repos and interacting with code.
Field helps here by adding custom fields to annotate data within Pydantic classes. Examples include description:
Python
classTrack(BaseModel): Name: str= Field(description="Track's name and mix.")
And examples:
Python
classTrack(BaseModel): Name: str= Field(description="Track's name and mix.",examples=["Track Title (Original Mix)", "Track Title (Extended Mix)"])
Using these throughout my Track class simplifies the code and reduces context switching:
Python
classTrack(BaseModel): Name: str= Field(description="Track's name and mix.",examples=["Track Title (Original Mix)", "Track Title (Extended Mix)"]) Artist: str= Field(description="The artist(s) of the track.",examples=["Above & Beyond", "Armin van Buuren"]) Album: str= Field(description="Track's Camelot Notation indicating the key.",examples=["01A-Abm", "02B-GbM"]) Work: str= Field(description="The record label that published the track.",examples=["Armada Music", "Anjunabeats"]) Genre: str= Field(description="Track's musical genre.",examples=["Trance", "Progressive House"]) TrackNumber: int= Field(description="Track's BPM (Beats Per Minute).",examples=[130, 140]) Year: int= Field(description="Track's release year.",examples=[1998, 2004]) MyRating: int= Field(description="Personal Rating. Stars expressed as 0, 20, 40, 60, 80, or 100",examples=[60, 80]) Location: FilePath = Field(description="Track's Location on the filesystem.",examples=[r"C:\Users\User\Music\iTunes\TranquilityBase-GettingAway-OriginalMix.mp3"])
This is especially useful for Album and TrackNumber given their unique properties.
Field Constraints
Field can also constrain the data that a class accepts. This includes string constraints:
max_length: Maximum length of the string.
min_length: Minimum length of the string.
pattern: A regular expression that the string must match.
ge & le – greater than or equal to/less than or equal to
gt & lt – greater/less than
multiple_of – multiple of a given number
Constraints can also be combined as needed. For example, iTunes exports record MyRating values in increments of 20, where 1 star is 20 and 2 stars are 40, rising to the maximum 5 stars being 100.
I can express this within the Track class as:
Python
classTrack(BaseModel): MyRating: int= Field(description="Personal Rating. Stars expressed as 0, 20, 40, 60, 80, or 100",examples=[60, 80],ge=20,le=100,multiple_of=20)
Here, MyRating must be greater than or equal to 20 (ge=20), less than or equal to 100 (le=100), and must be a multiple of 20 (multiple_of=20).
I can also parameterise these constraints using variables instead of hard-coded values:
Python
ITUNES_RATING_RAW_LOWEST=20ITUNES_RATING_RAW_HIGHEST=100classTrack(BaseModel): MyRating: int= Field(description="Personal Rating. Stars expressed as 0, 20, 40, 60, 80, or 100",examples=[60, 80],ge=ITUNES_RATING_RAW_LOWEST,le=ITUNES_RATING_RAW_HIGHEST,multiple_of=20)
This property lets me use Pydantic with other Python libraries. Here, my Year validation checks for years greater than or equal to 1970 and less than or equal to the current year (using the datetime library):
No track in the collection should exist beyond the current year – this constraint will now update itself as time passes.
Having applied other constraints, my Track class looks like this:
Python
classTrack(BaseModel):"""Pydantic model for validating iTunes track metadata.""" Name: str= Field(description="Track's name and mix type.",examples=["Track Title (Original Mix)", "Track Title (Extended Mix)"]) Artist: str= Field(description="The artist(s) of the track.",examples=["Above & Beyond", "Armin van Buuren"]) Album: str= Field(description="Track's Camelot Notation indicating the key.",examples=["01A-Abm", "02B-GbM"]) Work: str= Field(description="The record label that published the track.",examples=["Armada Music", "Anjunabeats"]) Genre: str= Field(description="Track's musical genre.",examples=["Trance", "Progressive House"]) TrackNumber: int= Field(description="Track's BPM (Beats Per Minute).",examples=[130, 140],ge=BPM_LOWEST,le=BPM_HIGHEST) Year: int= Field(description="Track's release year.",examples=[1998, 2004],ge=YEAR_EARLIEST,le=YEAR_CURRENT) MyRating: int= Field(description="Personal Rating. Stars expressed as 0, 20, 40, 60, 80, or 100",examples=[60, 80],ge=ITUNES_RATING_RAW_LOWEST,le=ITUNES_RATING_RAW_HIGHEST,multiple_of=20) Location: FilePath = Field(description="Track's Location on the filesystem.",examples=[r"C:\Users\User\Music\iTunes\AboveAndBeyond-AloneTonight-OriginalMix.mp3"])
This is already very helpful. Next, let’s examine my custom requirements.
Pydantic Custom Validation
This section discusses how to create custom data validation using Pydantic. I will outline what the requirements are, and then examine how these validations are defined and implemented.
Introducing Decorators
In Python, decorators modify or enhance the behaviour of functions or methods without changing their actual code. Decorators are usually written using the @ symbol followed by the decorator name, just above the function definition:
Python
@my_decoratordefmy_function():...
For example, consider this logger_decorator function:
Python
deflogger_decorator(func):defwrapper():print(f"Running {func.__name__}...") func() # Execute the supplied functionprint("Done!")return wrapper
This function takes another function (func) as an argument, printing a message before and after execution. If the logger_decorator function is then used as a decorator when running this greet function:
Python will add the logging behaviour of logger_decorator without modifying greet:
Python
Running greet...Hello, world!Done!
Introducing Field Validators
In addition to the built-in data validation capabilities of Pydantic, custom validators with more specific rules can be defined for individual fields using Field Validators. These use the field_validator() decorator, and are declared as class methods within a class inheriting from Pydantic’s BaseModel.
Here’s a basic example using my Track model:
Python
classTrack(BaseModel): Name: str= Field(description="Track's name and mix.",examples=["Track Title (Original Mix)", "Track Title (Extended Mix)"] )@field_validator("Name")@classmethoddefvalidate_name(cls, value):# custom validation logic herereturn value
Where:
@field_validator("Name") tells Pydantic to use the function to validate the Name field.
@classmethod lets the validator access the Track class (cls).
The validator executes the validate_name function with the field value (in this case Name) as input, performs the checks and must either:
return the validated value, or
raise a ValueError or TypeError if validation fails.
Let’s see this in action.
Null Checks
Firstly, let’s perform a common data validation check by identifying empty fields. I have two variants of this – one for strings and another for numbers.
The first – validate_non_empty_string – uses pandas.isna to catch missing values and strip() to catch empty strings. This field validator applies to the Artist, Work and Genre columns:
Python
@field_validator("Artist", "Work", "Genre")@classmethoddefvalidate_non_empty_string(cls, value, info):"""Validate that a string field is not empty."""if pd.isna(value) orstr(value).strip() =="":raiseValueError(f"{info.field_name} must not be null or empty")return value
The second – validate_non_null_numeric – checks the TrackNumber, Year and MyRating numeric columns for empty values using pandas.isna:
Python
@field_validator("TrackNumber", "Year", "MyRating", mode="before")@classmethoddefvalidate_non_null_numeric(cls, value, info):"""Validate that a numeric field is not null."""if pd.isna(value):raiseValueError(f"{info.field_name} must not be null")return value
Also, it uses Pydantic’s before validator (mode="before"), ensuring the data validation happens beforePydantic coerces types. This catches edge cases like "" or "NaN" before they become None or float("nan") values.
Character Check
Now let’s create a validator for something a little more challenging to define. All tracks in my collection follow a Track Name (Mix) schema. This can take many forms:
Original track: Getting Away (Original Mix)
Remixed track: Shapes (Oliver Smith Remix)
Updated remixed track: Distant Planet (Menno de Jong Interpretation) (2020 Remaster)
…and many more variants.
But generally, there should be at least one instance of text enclosed by parentheses. However, some tracks have no remixer and are released with just a title:
Getting Away
Shapes
Distant Planet
This not only looks untidy (eww!), but also breaks some of my downstream automation that expects the Track Name (Mix) schema. So any track without a remixer gets (Original Mix) added to the Name field upon download:
Getting Away (Original Mix)
Shapes (Original Mix)
Distant Planet (Original Mix)
Expressing this is possible with RegEx, but I can make a more straightforward and more understandable check with a field validator:
Python
@field_validator("Name")@classmethoddefvalidate_name(cls, value):if pd.isna(value) orstr(value).strip() =="":raiseValueError("Name must not be null or empty") value_str =str(value)if'('notin value_str:raiseValueError("Name must contain an opening parenthesis '('")if')'notin value_str:raiseValueError("Name must contain a closing parenthesis ')'")return value
This validator checks that the value isn’t empty and then performs additional checks for parentheses. This could be one check, but having it as two checks improves log readability (insert foreshadowing – Ed). I could also have added Name to the validate_non_empty_string validation, but this way I have all my Name checks in the same place.
Parameterised Checks
Like constraints, field validators can also be parameterised. Let’s examine Album.
As iTunes exports can’t be customised, I use Album for a track’s Camelot Notation. These are based on the Camelot Wheel – MixedInKey‘s representation of the Circle Of Fifths. DJs generally favour Camelot Notation as it is simpler than traditional music notation for human understanding and application sorting.
Importantly, there are only twenty-four possible notations:
For example:
1A (A-Flat Minor)
6A (G Minor)
6B (B-Flat Major)
10A (B Minor)
So let’s capture these values in a CAMELOT_NOTATIONS list:
(Note the leading zeros. Without them, iTunes sorts the Album column as (10, 11, 12, 1, 2, 3…) – you can imagine how I felt about that – Ed)
Next, I pass the CAMELOT_NOTATIONS list to an Album field validator that checks if the given value is in the list:
Python
@field_validator("Album")@classmethoddefvalidate_album(cls, value):if pd.isna(value) orstr(value).strip() =="":raiseValueError("Album must not be null or empty")ifstr(value) notinCAMELOT_NOTATIONS:raiseValueError(f"Album must be a valid Camelot notation: {value} is not in the valid list")return value
Pydantic now fails any value not found in the CAMELOT_NOTATIONS list.
Now I have my validation needs fully covered. What observability does Pydantic give me over these data validation checks?
Pydantic Observability
In this section, I assess and adjust the default Pydantic observability abilities to ensure my data validation is accurately recorded.
Default Output
Pydantic automatically generates data validation error messages if validation fails. These detailed messages provide a structured overview of the issues encountered, including:
The index of the failing input (e.g., a DataFrame row number).
The model class where the error occurred.
The field name that failed validation.
A human-readable explanation of the issue.
The offending input value and its type.
A direct link to relevant documentation for further guidance.
Here’s an example of Pydantic’s output when a string field receives a NaN value:
Python
Row 2353: 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_type
In this example:
Row 2353 indicates the problematic input row.
Track is the Pydantic model where validation failed.
Work is the failing field.
Pydantic detects that the input is nan (a float) and not a valid string.
Pydantic provides a URL to the string_type documentation.
Here’s another example, this time for a MyRating error:
Python
Row 3040: 1 validation error for TrackMyRating Value error, MyRating must not be null [type=value_error, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/value_error
In this case, a field validator raised a ValueError because MyRating must not be null.
Pydantic’s error reporting is clear and actionable, making it suitable for debugging and systemic data validation tasks. However, for larger datasets or more user-friendly outputs (such as reports or UI feedback), further customisation is helpful, such as…
Terminal Output Customisation
As good as Pydantic’s default output is, it’s not that human-readable. For example, in this Terminal output I have no idea which tracks are on rows 2353, 2495 and 3040:
Plaintext
Row 2353: 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_typeRow 2495: 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_typeRow 3040: 1 validation error for TrackMyRating Value error, MyRating must not be null [type=value_error, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/value_error
While I can find this out, it would be better to know at a glance. Fortunately, I can improve this when capturing the errors by appending the artist and name to each row of the errors object:
Python
except (ValidationError, ValueError) as e: artist = row['Artist'] ifnot pd.isna(row['Artist']) else"Unknown Artist" name = row['Name'] ifnot pd.isna(row['Name']) else"Unknown Name" errors.append((index, artist, name, str(e)))
Now, Artist and Name are added to each row:
Plaintext
Row 2353: Ben Stone - Mercure (Extended Mix): 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_typeRow 2495: DJ Hell - My Definition Of House Music (Resistance D Remix): 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_typeRow 3040: York - Reachers Of Civilisation (In Search Of Sunrise Mix): 1 validation error for TrackMyRating Value error, MyRating must not be null [type=value_error, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/value_error
This makes it far easier to find the problematic files in my collection. As long as there aren’t many findings…
Creating An Error File
There are three main problems with Pydantic printing all data validation errors in the Terminal:
They don’t persist outside of the Terminal session.
The Terminal isn’t that easy to read when it’s full of text.
The Terminal may run out of space if there are a large number of errors.
So let’s capture the errors in a file instead. This write_error_report function generates a text-based error report from validation failures, saving it in a logs subfolder adjacent to the input file:
Firstly, it constructs a timestamped filename using the original file’s stem (e.g., 20250529-142304-PydanticErrors-data.txt) and the logs subfolder, creating the latter if it doesn’t exist:
Next, Python orders the errors by the sorted_fields input, displays error counts per field and formats each error message with clear section dividers. A structured report listing all validation errors by field is saved in the logs subfolder:
Python
withopen(error_output_path, 'w', encoding='utf-8') as f: f.write(f"Validation Error Report - {timestamp}\n") f.write("="*80+"\n")for field in sorted_fields: messages = field_error_details.get(field, [])if messages: f.write(f"\n{field} Errors ({len(messages)}):\n") f.write("-"*80+"\n")for message in messages: f.write(message +"\n\n")
Finally, the filesystem path of the generated report is returned:
Python
return error_output_path
When executed, the Terminal tells me the error file path:
Plaintext
Detailed error log written to: 20250513-133743-PydanticErrors-iTunes-Elec-Dance-Club-Main.txt
And stores the findings in a local txt file, grouped by error type for simpler readability:
Plaintext
Validation Error Report - 20250513-133743================================================================================MyRating Errors (5):--------------------------------------------------------------------------------Row 3040: York - Reachers Of Civilisation (In Search Of Sunrise Mix): 1 validation error for TrackMyRating Value error, MyRating must not be null [type=value_error, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/value_errorWork Errors (22):--------------------------------------------------------------------------------Row 223: Dave Angel - Artech (Original Mix): 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_type
Adding A Terminal Summary
Finally, I created a Terminal summary of Pydantic’s findings:
Python
print("\nValidation Summary:\n")sorted_fields =sorted(Track.model_fields.keys())for field in sorted_fields: count = error_analysis['counts'].get(field, 0)print(f"{field} findings: {count}")
In this section, I test that my Pydantic data validation and observability processes are working correctly using iTunes export files and pytest unit tests.
Recent File Test
The first test used a recent export from the end of April 2025. Here is the Terminal output:
Plaintext
Processing file: iTunes-Elec-Dance-Club-Main-2025-04-28.txtReading iTunes-Elec-Dance-Club-Main-2025-04-28.txt with detected encoding UTF-16Loaded 4407 rowsValidated 4379 rowsFound 28 errors!Validation Summary for iTunes-Elec-Dance-Club-Main-2025-04-28.txt:Album errors: 0Artist errors: 0Genre errors: 0Location errors: 0MyRating errors: 5Name errors: 1TrackNumber errors: 0Work errors: 22Year errors: 0Detailed error log written to: 20250521-164324-PydanticErrors-iTunes-Elec-Dance-Club-Main-2025-04-28.txt
Good first impressions – the 4407 row count matches the export file, the summary is shown in the Terminal and an error log is created. So what’s in the log?
Firstly, five tracks have no MyRating values. For example:
Plaintext
MyRating Errors (5):--------------------------------------------------------------------------------Row 558: Reel People Feat Angela Johnson - Can't Stop (Michael Gray Instrumental Remix): 1 validation error for TrackMyRating Value error, MyRating must not be null [type=value_error, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/value_error
This is correct, as this export was created when I added some new tracks to my collection.
Next, one track has a Name issue:
Plaintext
Name Errors (1):--------------------------------------------------------------------------------Row 1292: The Prodigy - Firestarter (Original Mix}: 1 validation error for TrackName Value error, Name must contain a closing parenthesis ')' [type=value_error, input_value='Firestarter (Original Mix}', input_type=str] For further information visit https://errors.pydantic.dev/2.11/v/value_error
This one confused me at first, until I looked at the error more closely and realised the closing parenthesis is wrong! } is used instead of )! This is why my validate_name field validator has separate checks for each character – it makes it easier to understand the results!
Finally, twenty-two tracks are missing record label metadata in Work:
Plaintext
Work Errors (22):--------------------------------------------------------------------------------Row 223: Dave Angel - Artech (Original Mix): 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_type
This means some tracks are missing full metadata. This won’t break any downstream processes as I have no reliance on this field. That said, it’s good to know about this in case my future needs change.
Older File Test
The next test uses an older file from March 2025. Let’s see what the Terminal says this time…
There are fewer rows here – 4381 vs 4407. This is correct, as my collection was smaller in March. But no rows were validated successfully!
I don’t have to go far to find out why:
Plaintext
Location Errors (4381):--------------------------------------------------------------------------------Row 0: Ariel - A9 (Original Mix): 1 validation error for TrackLocation Path does not point to a file [type=path_not_file, input_value='C:\\Users\\User\\Folder...riel-A9-OriginalMix.mp3', input_type=str]
All the location checks failed. But this is actually a successful test!
In the time between these two exports, I reorganised my music collection. As a result, the file paths in this export no longer exist. Remember – the Location field uses the FilePath data type, which checks that the given paths exist and link to valid files. And these don’t!
The Name results are the same as the first test. This has been around for a while apparently…
Plaintext
Name Errors (1):--------------------------------------------------------------------------------Row 1292: The Prodigy - Firestarter (Original Mix}: 1 validation error for TrackName Value error, Name must contain a closing parenthesis ')' [type=value_error, input_value='Firestarter (Original Mix}', input_type=str] For further information visit https://errors.pydantic.dev/2.11/v/value_error
There are also TrackNumber errors in this export:
Plaintext
TrackNumber Errors (2):--------------------------------------------------------------------------------Row 485: Andrew Bayer Feat Alison May - Brick (Original Mix): 2 validation errors for TrackTrackNumber Input should be greater than or equal to 100 [type=greater_than_equal, input_value=90, input_type=int] For further information visit https://errors.pydantic.dev/2.11/v/greater_than_equal
Two tracks have BPM values lower than the set range. Both files were moved during my reorganisation, but were included in this export at the time and therefore fail this validation check.
Finally, the Work errors are the same as the first test (although more have crept in since!):
Plaintext
Work Errors (17):--------------------------------------------------------------------------------Row 223: Dave Angel - Artech (Original Mix): 1 validation error for TrackWork Input should be a valid string [type=string_type, input_value=nan, input_type=float] For further information visit https://errors.pydantic.dev/2.11/v/string_type
Ultimately, both tests match expectations!
Unit Tests With Amazon Q
Finally, I wanted to include some unit tests for this project. Unit testing is always a good idea, especially in this context where I can verify function outputs and error generation without needing to create numerous test files.
I figured this was a good opportunity to test Amazon Q Developer and see what it came up with. I gave it a fairly basic prompt, using the @workspace context to allow Q access to my project’s entire workspace as context for its responses:
Plaintext
@workspace write unit tests for this script using pytest
I tend to use pytest for my Python testing, as I find it simpler and more flexible than Python’s standard unittest library.
Q promptly provided several reasonable tests in response. This initiated a half-hour exchange between us focused on calibrating the existing tests and creating new ones. To be fair to Q, my initial prompt was quite basic and could have been much more detailed.
Amongst Q’s tests was this one testing an empty Artist field:
Python
@patch('pathlib.Path.exists')deftest_empty_artist(self, mock_exists):"""Test that an empty artist fails validation."""# Mock file existence check mock_exists.return_value =True invalid_track_data = {"Name": "Test Track (Original Mix)","Artist": "", # Empty artist"Album": "01A-Abm","Work": "Test Label","Genre": "Trance","TrackNumber": 130,"Year": 2020,"MyRating": 80,"Location": "C:\\Music\\test_track.mp3" }
This one, checking an invalid Camelot Notation:
Python
@patch('pathlib.Path.exists')deftest_invalid_album_not_camelot(self, mock_exists):"""Test that an invalid Camelot notation fails validation."""# Mock file existence check mock_exists.return_value =True invalid_track_data = {"Name": "Test Track (Original Mix)","Artist": "Test Artist","Album": "Invalid Key", # Not a valid Camelot notation"Work": "Test Label","Genre": "Trance","TrackNumber": 130,"Year": 2020,"MyRating": 80,"Location": "C:\\Music\\test_track.mp3" }with pytest.raises(ValueError, match="Album must be a valid Camelot notation"): Track(**invalid_track_data)
And this one, checking what happens with an incomplete DataFrame:
Python
@patch('wolfie_exportvalidator_itunes.detect_file_encoding')@patch('pandas.read_csv')deftest_load_itunes_data_missing_columns(self, mock_read_csv, mock_detect_encoding):"""Test loading iTunes data with missing columns."""# Setup mocks mock_detect_encoding.return_value ='utf-8' mock_df = pd.DataFrame({'Name': ['Test Track (Original Mix)'],'Artist': ['Test Artist'],# Missing required columns }) mock_read_csv.return_value = mock_df# Call function and verify it raises an errorwith pytest.raises(ValueError, match="Missing expected columns"): load_itunes_data(Path('dummy_path.txt'))
I’ll include the whole test suite in my GitHub repo. Let’s conclude with pytest‘s output:
I had a very positive experience overall! Working with Amazon Q allowed me to write the tests more quickly than I could have done on my own. We would have been even faster if I had put more thought into my initial prompt. Additionally, since Q Developer offers a generous free tier, it didn’t cost me anything.
GitHub Repo
I have committed my Pydantic data validation script, test suite and documentation in the repo below:
Note that the parameters are decoupled from the Pydantic script. This will allow me to reuse some parameters across future validation scripts and has enabled me to exclude the system parameters from the repository.
Summery
In this post, I used the Pydantic Python library to create data validation and observability processes for my Project Wolfie iTunes data.
I found Pydantic very impressive! Its simplicity, functionality and interoperability make it an attractive addition to Python data pipelines, and its strong community support keeps Pydantic relevant and current. Additionally, Pydantic’s presence in FastAPI, PydanticAI and a managed AWS Lambda layer enables rapid integration and seamless deployment. I see many applications for it within Project Wolfie.
There’s lots more to Pydantic – this Pixegami video is a great walkthrough of Pydantic in action:
If this post has been useful then the button below has links for contact, socials, projects and sessions:
I first found O’Reilly books a few years back in a Data Engineering-themed Humble Bundle. Since then, I’ve built an extensive library of both e-books and physical books, with many more on my Amazon wish list. At the start of 2025, I decided to actually start reading them…
So far, I’ve finished three. Now, I don’t feel compelled to review them all. But having finished Practical Lakehouse Architecture I decided to start the Shark Shelf. This will be an occasional series of review posts about books that I really like, or that deserve some fanfare. And yes – How To Solve Itbelongs on the Shark Shelf.
Now let’s talk about Practical Lakehouse Architecture.
The Author
Gaurav Ashok Thalpati hails from Pune, India, where he’s worked as an independent cloud data consultant for decades. He’s a blogger and YouTuber, holds multiple data certifications and is an AWS Community Builder.
In July 2024, O’Reilly published his first book, Practical Lakehouse Architecture.
The Book
From the Practical Lakehouse Architecture blurb:
This guide explains how to adopt a data lakehouse architecture to implement modern data platforms. It reviews the design considerations, challenges, and best practices for implementing a lakehouse and provides key insights into the ways that using a lakehouse can impact your data platform, from managing structured and unstructured data and supporting BI and AI/ML use cases to enabling more rigorous data governance and security measures.
Practical Lakehouse Architecture was released in July 2024. It is available in both physical and eBook forms from O’Reilly, Amazon US, Amazon UK and eBooks.
Motivations
Reading a book?! In 2025?! I know, right? This section examines my motivations for buying and reading Practical Lakehouse Architecture.
Project Wolfie
I recently wrote about the beginning of Project Wolfie. I kinda expected to have started coding by now. Instead, most of my work is currently on paper and whiteboards. But there’s a good reason for this.
Project Wolfie is greenfield. I don’t have any existing code or resources, and I can use modern tools freely. However, with this freedom comes responsibility. Every choice I make now affects the architecture and involves tradeoffs. As much as I want to start working on the deliverables, I also want to make sensible decisions that can withstand scrutiny.
My hope with Practical Lakehouse Architecture was that it would help me with critical areas like observability, CI/CD, and security. Because it’s not that there isn’t advice online…
Advice Spread Thin
Lakehouse architectures are relatively recent in the data landscape. As a result, their understanding is not as established as that of data warehouses and data lakes, and some aspects of Lakehouse architecture are still evolving.
Many Lakehouse resources are either brief overviews, opinionated deep dives into specific use cases or marketing posts acting as best practices. This makes it hard to find balanced advice. My hope with Practical Lakehouse Architecture was that it would offer clear, unbiased views.
Professional Curiosity
As of 2025, I’ve spent nearly a decade in technical data roles. And in that time I’ve seen massive changes in data management, ranging from a server cupboard in Stockport to huge, multi‑region distributed data platforms.
Over the years, I’ve cultivated a passion for data technology, evolving from writing blog posts and speaking at meetups to working as an AWS consultant. As an AWS Community Builder in the Data category, I can access early previews and best practices from AWS experts. Additionally, as an AWS User Group Leader, I help attendees and guest speakers discuss data patterns.
With this in mind, I was curious about what new insights Practical Lakehouse Architecture could offer me.
Book Review
Onto the review! In this section, I’ll summarise the chapters and examine what stood out in each.
Chapters 1 – 3
The first set of chapters introduces the foundations of Lakehouse architecture, comparing it with traditional models and exploring the importance of storage in modern data platforms.
Chapter 1: Introduction to Lakehouse Architecture lays the groundwork for the book, putting all readers on equal footing for the chapters ahead. Gaurav starts by defining and exploring the ideas and concepts of various data architectures. He then examines the characteristics, evolution and benefits of the Lakehouse architecture.
Chapter 2: Traditional Architectures and Modern Platforms contrasts the Lakehouse architecture with traditional data lakes and data warehouses, outlining the benefits and limitations of each. Gaurav then shifts his focus to how modern cloud platforms have transformed these traditional architectures.
I like how Gaurav hasn’t dismissed lakes and warehouses here. Both are proven and well-understood options, and they are still the better choice in certain situations over Lakehouses.
Chapter 3: Storage: The Heart Of The Lakehouse examines the various factors surrounding data storage. Gaurav looks at row-based and column-based storage formats. He then explains the features and uses of Parquet, ORC, and Avro. He also compares newer open table formats, like Iceberg, Hudi, and Delta Lake, highlighting their similarities, differences, and use cases.
This is one area where the book really shines. Having topics like this explained clearly in one place, without having to go online, is incredibly useful!
Chapters 4 – 6
Next, these chapters focus on the operational and organisational elements of Lakehouse architectures. Topics include metadata management, compute engines, and governance. These elements are essential for effectively scaling and securing a modern data platform.
Chapter 4: Data Catalogs explores the purpose of data catalogs and the different types of metadata they can contain. It explains how catalogs support essential processes such as classification, governance, and lineage. Gaurav also compares data catalog implementations across AWS, Azure, and GCP.
Including multi-cloud examples both broadens the chapter’s scope and reinforces the cloud-agnostic nature of Lakehouse architecture – an important theme of the book.
Chapter 5: Compute Engines for Lakehouse Architectures examines compute options for batch and real-time data processing. Gaurav covers open-source tools such as Spark, Flink, and Presto, as well as cloud-native services like AWS Glue, Google BigQuery, and Databricks. He offers practical advice for selecting a compute engine, considering factors such as provisioning complexity, open-source support and AI/ML capabilities.
Chapter 6: Data and AI Governance and Security in Lakehouse Architecture explores governance and security, crucial areas for any production-ready data platform. Gaurav discusses core topics such as data quality, ownership, sensitivity and compliance. He also explores how governance responsibilities span both business and technical domains, emphasising the importance of organisational roles in maintaining control and oversight.
Chapters 7 – 9
Finally, these chapters focus on the practical realities of Lakehouse implementation – moving between theory and practice, and looking ahead to the architecture’s potential future.
Chapter 7: The Big Picture: Designing and Implementing a Lakehouse Platform examines considerations ranging from requirements gathering to defining business goals. Recommended Lakehouse zones are analysed and explained, and the expectations for each zone are defined. Finally, CICD is considered, and a sample design questionnaire is provided to help guide implementation planning.
Zones, or layers, are currently one of the most contentious areas of Lakehouse architectures. I like Gaurav’s stance on this – it’s somewhat similar to Simon Whiteley‘s. Yup – this video again.
Chapter 8: Lakehouse in the Real World does something I don’t see often – contrasting ideal scenarios with real-world events. It covers key stages in a Lakehouse’s development like analysis, testing and maintenance, examining what could go wrong and offering mitigation strategies.
This section is definitely accurate, as I’ve encountered some of these factors! It includes comparing greenfield and brownfield implementations, examining how business constraints affect technology choices, and considering if the desired RPO and RTO targets are financially and logistically possible.
Finally, Chapter 9: Lakehouse Of The Future looks ahead, exploring how Lakehouses might evolve in the years to come. Gaurav discusses potential intersections with trends like Data Mesh, Zero ETL and AI model integration. He also introduces emerging technologies like Delta UniForm and Apache XTable, which aim to improve interoperability across data processing systems and query engines. Finally, he touches on future innovations such as Apache Puffin and Ververica Streamhause that could further transform the data landscape.
(Sidenote: this Dremio post explores UniFrom and XTable very well.)
Thoughts
Having finished the book (in two weeks no less!), here are my thoughts:
Firstly, it’s not an intimidating read. At 283 pages, Practical Lakehouse Architecture is authoritative and content-rich without being overly complex or wordy. It also uses familiar O’Reilly conventions and style. When placed next to similar books I own, like The Data Warehouse Toolkit (600 pages) and Designing Data-Intensive Applications (614 pages), it’s easier to pick up and get into. And with some books, that’s a battle in itself!
Also, Practical Lakehouse Architecture‘s flow is very natural and the chapters make their points very well. I find some technical books, including some O’Reilly ones, hard to follow because they feel disjointed and jargon-heavy. That wasn’t the case here. The book held my attention very well throughout, and will serve me well as a future reference point.
Practical Lakehouse Architecture also feels like it will be relevant for a while. Some of my technical books have sections that are now outdated due to rapid technological changes. Here, ideas such as decoupled storage and compute, unified governance, and data personas will continue to matter for years to come.
Overall, an excellent book that I enjoyed reading.
Summary
In this post, I reviewed Gaurav Ashok Thalpati’s 2024 book ‘Practical Lakehouse Architecture‘ published by O’Reilly Media.
Ultimately, Practical Lakehouse Architecture is a well-written and informative book that caters to a wide range of skills. It’s a strong addition to the O’Reilly catalogue and complements titles like Rukmani Gopalan‘s 2022 book, The Cloud Data Lake, which I’m currently reading. It’s a great knowledge source for this constantly evolving modern data architecture.
If this post has been useful then the button below has links for contact, socials, projects and sessions:
