Scribbles for my bad memory

Writing commit message could be time-consuming if you want a good summrize. ChatGPT just released their cheapest but still powerful model gpt-4o-mini, we can use it to save our time and keep the commit message accurate.

You need to put your API KEY in environment variable OPENAI_API_KEY before running this script. You need to run git add first before running this ci script. If you don't want to bother adding first, change git diff --cached -w -b to git diff -w -b and add -a option in the commit command (the last line of the script)

#!/bin/bash

# Get git changes
changes=$(git diff --cached -w -b)

# Exit if no changes
if [ -z "$changes" ]; then
  echo "No changes to commit."
  exit 0
fi

# Set prompt template
prompt_template=$(cat <<-END
You are good at writing git commit messages;
You follow the conventional commits specification:

feat: for new features
chore: for maintenance work
fix: for bug fixes

Please help write a commit message for the following changes from a `git diff` command.
Please try to summerize all meaningful changes while keep the result short.
THE RESULT SHOULD ONLY BE NO MORE THEN 100 CHARACTERS.

please do not respond any other information/text rather than the commit message itself.
and here're the changes:

END
)

prompt_template+="$changes"

# Build JSON request body using jq
request_body=$(jq -n --arg model "gpt-4o-mini-2024-07-18" --arg prompt "$prompt_template" \
  '{model: $model, messages: [{role:"system",content:"You are a programmer"},{role: "user", content: $prompt}], max_tokens: 32768, seed: 45, temperature: 0}')

# Use curl to request the OpenAI API to generate a commit message
response=$(curl -s --request POST \
  --url https://api.openai.com/v1/chat/completions \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-Type: application/json" \
  --data "$request_body")

# Extract commit message from the response
commit_message=$(echo "$response" | jq -r '.choices[0].message.content')

# Exit if the commit message is empty
if [ -z "$commit_message" ]; then
  echo 'failed to generate a commit message'
  exit 1
fi

# Commit changes
git commit -m "$commit_message"

2024-07-24 update

Free alternative provided by Groq

If you don't want to pay for the ChatGPT API, you can opt for the free alternative provided by Groq. To get started, simply sign up for a Groq account using Google Login. Once you've created your account, you can generate an API key by following this link: https://console.groq.com/keys. Finally, make a minor modification to your script, as outlined below.

# Build JSON request body using jq
#request_body=$(jq -n --arg model "gpt-4o-mini-2024-07-18" --arg prompt "$prompt_template" \
#  '{model: $model, messages: [{role:"system",content:"You are a programmer"},{role: "user", content: $prompt}], max_tokens: 50, seed: 45, temperature: 0}')
#response=$(curl -s --request POST \
#  --url https://api.openai.com/v1/chat/completions \
#  --header "Authorization: Bearer $OPENAI_API_KEY" \
#  --header "Content-Type: application/json" \
#  --data "$request_body")

request_body=$(jq -n --arg model "mixtral-8x7b-32768" --arg prompt "$prompt_template" \
  '{model: $model, messages: [{role:"system",content:"You are a programmer"},{role: "user", content: $prompt}], max_tokens: 32768, stream: false, temperature: 0, top_p: 1, stop: null}')

# Use curl to request the OpenAI API to generate a commit message
response=$(curl -s --request POST \
  --url https://api.groq.com/openai/v1/chat/completions \
  --header "Authorization: Bearer $GROQ_API_KEY" \
  --header "Content-Type: application/json" \
  --data "$request_body")

The Dart ... spread operator is a powerful feature that allows you to insert multiple elements from a collection into another collection. This is particularly useful when building Flutter widget trees, as it can make your code more concise and readable.

What is the Spread Operator ...?

The ... operator is used to expand elements of a collection and add them to another collection. For example:

List<int> list1 = [1, 2, 3];
List<int> list2 = [0, ...list1, 4];
print(list2); // Output: [0, 1, 2, 3, 4]

Using the Spread Operator in Flutter Widgets

In Flutter, you can use the ... operator to conditionally add multiple widgets to a widget list, making the code cleaner and more maintainable.

Without the Spread Operator

If you don't use the ... operator, you might end up writing repetitive conditional checks like this:

AppBar(
  title: const Text('Note Details'),
  actions: [
    if (widget.note.userId == UserSession().id)
      IconButton(
        icon: const Icon(Icons.edit),
        onPressed: _enterEditingMode,
      ),
    if (widget.note.userId == UserSession().id)
      IconButton(
        icon: const Icon(Icons.delete),
        onPressed: () async {
          await DialogService.showConfirmDialog(
            context,
            title: 'Delete note',
            text: 'Each note is a story, are you sure you want to delete it?',
            yesCallback: () => _controller.deleteNote(context, widget.note.id),
          );
        },
      ),
  ],
)

This approach involves duplicating the condition check for each widget, making the code verbose and harder to maintain.

With the Spread Operator

Using the ... spread operator, you can simplify the code by grouping the widgets under a single conditional check:

AppBar(
  title: const Text('Note Details'),
  actions: [
    if (widget.note.userId == UserSession().id) ...[
      IconButton(
        icon: const Icon(Icons.edit),
        onPressed: _enterEditingMode,
      ),
      IconButton(
        icon: const Icon(Icons.delete),
        onPressed: () async {
          await DialogService.showConfirmDialog(
            context,
            title: 'Delete note',
            text: 'Each note is a story, are you sure you want to delete it?',
            yesCallback: () => _controller.deleteNote(context, widget.note.id),
          );
        },
      ),
    ],
  ],
)

This method is more concise and only requires a single condition check, reducing redundancy and improving readability.

Benefits of Using the Spread Operator

1. Reduces Code Duplication: The spread operator allows you to write less code by removing the need for multiple conditional checks.
2. Improves Readability and Maintainability: With fewer lines of code and clearer structure, your code is easier to read and maintain.
3. Simplifies Conditional Addition of Multiple Elements: When you need to add multiple elements based on a condition, the spread operator provides a clean and efficient way to do so.

In a recent project, I ran into an issue where I needed to refresh a page when the user navigated back to it. After searching on google and asking ChatGPT, I found this simple and clean solution.

What is RouteObserver?

RouteObserver is part of the Flutter framework that helps you track navigation events in your app. It allows you to listen to changes in the route stack, such as when a route is pushed or popped. This is incredibly useful for scenarios where you need to refresh or update your UI based on navigation.

Setting Up RouteObserver

First, I created a UserSession class to hold a singleton instance of RouteObserver. Here’s the gist:

// user_session.dart
import 'package:flutter/material.dart';

class UserSession {
  static final UserSession _instance = UserSession._internal();
  static final routeObserver = RouteObserver<ModalRoute>();

  UserSession._internal();
}

By doing this, I could easily access routeObserver from anywhere in my app. My UserSession also holds other user session data, maybe a bettway is to create a separate file for RouteObserver. But for now, we just use the UserSession class.

Adding RouteObserver to Your App

Next, I needed to register this RouteObserver with my app’s navigator. I did this in the main app widget:

// main.dart
import 'package:flutter/material.dart';
import 'package:happy_notes/screens/account/user_session.dart';

class HappyNotesApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: const InitialPage(),
      navigatorObservers: [UserSession.routeObserver],
    );
  }
}

By adding UserSession.routeObserver to navigatorObservers, we’re now tracking route changes across the entire app.

Using RouteObserver in Screens

To use RouteObserver, I extended my state classes with RouteAware and subscribed to the routeObserver in the initState method. Here’s an example from the Memories screen:

// memories.dart
import 'package:flutter/material.dart';
import '../account/user_session.dart';

class MemoriesState extends State<Memories> with RouteAware {
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addPostFrameCallback((_) {
      UserSession.routeObserver.subscribe(this, ModalRoute.of(context)!);
    });
  }

  @override
  void didPopNext() {
    // Called when the top route has been popped off, and this route shows up
    _fetchMemories();
    setState(() {});
  }

  @override
  void dispose() {
    UserSession.routeObserver.unsubscribe(this);
    super.dispose();
  }
  
  void _fetchMemories() {
    // Logic to refresh memories
  }
}

Here’s what’s happening:

1. Subscription: In initState, the screen subscribes to routeObserver.
2. Route Events: The didPopNext method is triggered when the screen becomes visible again after another screen is popped off. This is where I refreshed the screen's data by calling _fetchMemories().
3. Unsubscription: It’s important to unsubscribe in the dispose method to avoid memory leaks.

Conclusion

Using RouteObserver in Flutter allows you to manage your app’s navigation state effectively. By listening to route changes, you can ensure that your UI stays in sync with user actions, providing a seamless experience.

Managing time zones can be tricky, especially in regions that observe daylight saving time (DST). Using the right time zone identifiers can simplify your work by automatically adjusting for these changes. Here’s a quick guide to best practices for handling time zones, using examples from New Zealand and Australia.

The Problem with Fixed Time Zones

The Problem with Fixed Time Zones Using fixed time zones like NZST (New Zealand Standard Time) typically doesn't account for daylight saving changes, potentially leading to incorrect time calculations during daylight saving periods. However, certain platforms, such as .NET, which handles these transitions internally, giving the correct local time. This behavior might not be consistent across different platforms and systems.

The Best Practice Solution

The best practice is to use time zone identifiers that handle both standard and daylight saving times automatically. These identifiers switch between standard time and daylight saving time based on the current date, keeping your times accurate year-round. For example:

• New Zealand: Use Pacific/Auckland.
• Australia: Use Australia/Sydney.
• United States: Use America/New_York for Eastern Time, America/Los_Angeles for Pacific Time, etc.

These identifiers know when to transition between standard time and daylight saving time, ensuring your applications reflect the correct local time.

In the HappyNotes project, I encountered a perplexing issue with the NoteModel not updating as expected across flutter widgets. Despite initializing NoteModel with initial values and using ChangeNotifierProvider, the state changes weren’t reflecting in the model when I try to collect data back. This article outlines the troubleshooting process and solution, which can be a valuable guide for other developers facing similar challenges.

Background

In HappyNotes project, the NewNote widget is where users could create notes. Each note had properties like isPrivate and isMarkdown, managed through a NoteModel using ChangeNotifier. Here’s a simplified version of the relevant parts of my setup:

class NoteModel extends ChangeNotifier {
  bool isPrivate;
  bool isMarkdown;

  NoteModel({this.isPrivate = true, this.isMarkdown = false});

  set isPrivate(bool value) {
    _isPrivate = value;
    notifyListeners();
  }

  set isMarkdown(bool value) {
    _isMarkdown = value;
    notifyListeners();
  }
}

The NewNote widget utilized ChangeNotifierProvider to provide the NoteModel to its children:

class NewNote extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => NoteModel(),
      child: Scaffold(
        appBar: AppBar(title: Consumer<NoteModel>(
          builder: (context, noteModel, child) {
            return Text(noteModel.isPrivate ? 'Private Note' : 'Public Note');
          },
        )),
        body: NoteEditor(),
      ),
    );
  }
}

The Problem

After setting the initial values for isPrivate and isMarkdown, later changes to these properties weren’t being reflected in the model when I retrieve the status data when saving a note . I tried various approaches, including manually calling notifyListeners and using setState within event handlers, but nothing solved the issue.

Troubleshooting Process

1. Double Check Initialization: First, I verified that NoteModel was being initialized correctly with the ChangeNotifierProvider. The initial values were correct, but subsequent changes weren’t propagating.

2. Use of Consumer:

I ensured that widgets depending on NoteModel used Consumer to listen for changes:

   Consumer<NoteModel>(
     builder: (context, noteModel, child) {
       return Switch(
         value: noteModel.isPrivate,
         onChanged: (value) {
           noteModel.isPrivate = value;
         },
       );
     },
   );

3. Spotting out the root cause: Multiple providers initialization:

Finally I found that having multiple ChangeNotifierProviders at different levels of the widget tree, is the root cause that leads to this issue. I shouldn't initialize the same model twice at the root level and at the page level.

The Solution

The breakthrough came when we adjusted our main application setup to use a single ChangeNotifierProvider for NoteModel:

void main() {
  runApp(
    ChangeNotifierProvider(
      create: (_) => NoteModel(),
      child: MyApp(),
    ),
  );
}

In NewNote, I removed the redundant ChangeNotifierProvider and directly used the globally provided NoteModel:

class NewNote extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Consumer<NoteModel>(
          builder: (context, noteModel, child) {
            return Text(noteModel.isPrivate ? 'Private Note' : 'Public Note');
          },
        ),
      ),
      body: NoteEditor(),
    );
  }
}

By centralizing NoteModel provisioning, state changes propagated correctly across the app. This resolved the issue, proving that a single ChangeNotifierProvider is the key for consistent state management in Flutter.

Key Takeaways

• Use a Single ChangeNotifierProvider: Ensure a single source of truth for state by providing your model at a high level in the widget tree.
• Leverage Consumer for Efficient Updates: Use Consumer to automatically rebuild parts of the UI that depend on the model, reducing manual state management.