Til Tracker

PDF tab title incorrect (comes from embedded metadata)

Issue: When I opened linked PDFs (cv.pdf, cover_letter.pdf), the browser tab showed an incorrect title (e.g., "Minimalist White and Grey Professional Resume").
Cause: The browser tab title for directly viewed PDFs is taken from the Title property embedded in the PDF's metadata, set when the PDF was created.
Resolution: I edited the PDF metadata using a dedicated PDF editor (Nitro PDF Pro, as Preview was insufficient) to change the Title property within each PDF file. I re-copied the modified PDFs to public/documents/.
Learning: The display title for linked assets like PDFs is controlled by the asset's internal metadata, not the HTML page linking to it. I learned editing requires tools capable of modifying PDF properties (Preview might not work; Acrobat, Nitro Pro, or other editors are needed).

Tags: frontend workflow debugging

Learned on: April 22, 2024 Edit

Routing Error for static files (`/documents/cv.pdf`) in development

Issue: Linking to PDFs I placed in public/documents/ resulted in No route matches [GET] /documents/cv.pdf in the development environment.
Cause: By default, the Rails development environment often doesn't serve static files from the public directory. This is typically enabled only in production for performance reasons.
Resolution:
1. I enabled static file serving in development by setting config.public_file_server.enabled = true in config/environments/development.rb.
2. I ensured the PDF files were correctly placed in til_tracker/public/documents/.
3. I restarted the Rails server (./bin/dev).
Learning: To serve static assets (like PDFs, images) directly from the public folder in the development environment, I learned I must explicitly set config.public_file_server.enabled = true in config/environments/development.rb and restart the server. In production, this is usually handled by the webserver (like Nginx or Apache) or enabled by default in production.rb.

Tags: rails-core environment-setup frontend error-handling debugging

Learned on: April 22, 2024 Edit

Clarification: CSS Styling Consolidation Effects

Context: We discussed visual changes after my CSS cleanup (buttons, fonts, tags).
Buttons: Change to blue (#007bff) resulted from my consolidating multiple previous rules for .button and input[type="submit"] into one consistent style for simplicity.
Fonts: Adding font-family: inherit; to form inputs/textareas ensures they use the main body font stack, improving consistency.
Tags: Change from pill-shaped (border-radius: 10rem;) to squared (border-radius: 4px;) was part of my cleanup for a cleaner look.
Learning: CSS consolidation aims for simplicity but can alter appearance. I learned that explicit styles (font-family: inherit;) prevent varying browser defaults. Intentional style changes should be noted.

Tags: css frontend ui ux refactoring button font tags consistency css-cleanup

Learned on: April 21, 2024 Edit

Clarification: Turbo's data-turbo-confirm attribute

Context: We discussed the purpose of data-turbo-confirm attribute.
Explanation: It's a Hotwire/Turbo HTML attribute (data-turbo-confirm="Are you sure?") that automatically triggers a browser confirmation dialog before executing a link click or form submission.
Use Case: Commonly used for destructive actions (like deletion) to prevent accidental clicks.
Learning: I learned to utilize standard Hotwire/Turbo attributes for common UX patterns like confirmation dialogs with minimal effort.

Tags: hotwire turbo javascript frontend ui ux html attribute

Learned on: April 21, 2024 Edit

CSS Layout Fix: Form container width

Issue: My form pages (/learnings/new, edit) appeared narrow after CSS cleanup.
Context: Applying max-width: 700px; to the .form-container class during CSS refactoring restricted the entire form area.
Resolution: I removed the max-width: 700px; rule from .form-container in application.css.
Learning: I learned to be mindful of the layout impact of CSS rules like max-width on containers. Testing responsiveness and appearance after changes is important.

Tags: css layout frontend ui ux debugging css-cleanup

Learned on: April 21, 2024 Edit

Seeded text displayed raw HTML & unstyled backticks

Context: The format_learning_body helper used sanitize: false to preserve <strong> tags, but this also allowed other raw HTML from the source text (like <input>) to render. Backticks (`) were preserved but had no special styling.
Resolution: I modified the format_learning_body helper:
1. Escape all HTML first (ERB::Util.html_escape).
2. Bold keywords (<strong>) on escaped string.
3. Wrap backticked content () with <code>` tags on bolded string.
4. Apply simple_format(..., sanitize: false) last.
5. Added CSS for code tag.
Learning: When displaying potentially unsafe text that also needs specific safe HTML formatting, I learned the order matters: Escape first, then selectively add safe tags, then apply structural formatting (like simple_format with sanitize: false).

Tags: seeds formatting view helper html css escaping sanitization code bold frontend debugging

Learned on: April 20, 2024 Edit

`rails db:seed` failed (NameError due to heredoc interpolation)

Context: I ran the generated seed script which populated Learning records from LEARNINGS.md. The error occurred processing an entry whose body contained the literal text params[:tag]. The default heredoc syntax (<<~BODY) attempted Ruby interpolation (#{...}) on this text, causing NameError: undefined local variable or method 'params' for main:Object.
Resolution: I changed the heredoc definition for the problematic entry in db/seeds.rb from <<~BODY to <<~'BODY' (note the single quotes). This prevents interpolation within that specific string, treating it literally.
Learning: I learned to be cautious when using interpolating heredocs (<<~DELIMITER) in seed files or scripts if the source text might contain #{}, ${}, or similar sequences that could be misinterpreted as code interpolation. Use non-interpolating heredocs (<<~'DELIMITER') or escape the relevant characters (\#{}) within the string if interpolation is needed elsewhere but not for specific literals.

Tags: seeds database ruby heredoc interpolation error debugging workflow

Learned on: April 20, 2024 Edit

Discussion: Native `date_field` vs alternatives

Discussion: I considered alternatives to the native HTML5 date_field due to inconsistent styling/icon placement across browsers (Chrome vs Firefox vs Safari).
Alternative Considered: Rails date_select helper (outputs three dropdowns: Year, Month, Day). Custom JS date pickers were ruled out by the 37signals philosophy.
Decision: I stuck with date_field for simplicity and reliance on native browser behavior, accepting the minor cross-browser styling limitations. I added (YYYY-MM-DD) format hint to the label for clarity, as placeholder text isn't supported consistently for date inputs.
Learning: Native form elements offer simplicity, accessibility, and avoid JS dependencies but have limited styling control. I learned to weigh the trade-offs between custom solutions (more control, more complexity/JS) and accepting native limitations based on project philosophy (e.g., 37signals favors simplicity and defaults). Providing clear labels and format hints is important.

Tags: frontend ui ux html css form date date_field date_select accessibility browser-compatibility 37signals decision

Learned on: April 19, 2024 Edit

Textarea font different from input fields

Issue: The font in the textarea (body field) differed from input fields (e.g., title).
Cause: Textareas often default to a monospace font in browsers, while other inputs might inherit the body font. The shared CSS rule for inputs/textarea didn't explicitly set font-family.
Resolution: I added font-family: inherit; to the shared CSS rule for input, textarea.
Learning: I learned to explicitly set font-family: inherit; on form controls (input, textarea, select, button) to ensure they consistently use the base font defined higher up in the CSS cascade (e.g., on body), avoiding default browser discrepancies.

Tags: frontend ui ux css html form font textarea input

Learned on: April 19, 2024 Edit

Form content indented compared to index page

Issue: My form content (.form-container) was slightly indented horizontally compared to the index page content.
Cause: The .form-container CSS rule had horizontal padding (padding: 0 1rem;) while the index page content relied on the body's margin or a container without that specific padding.
Resolution: I removed the horizontal padding (padding: 0 1rem;) from the .form-container CSS rule to align it with the index page's container.
Learning: I learned to ensure consistent container padding/margins across different page templates or layouts for visual alignment and a cohesive look. Inspecting element styles using browser dev tools is helpful.

Tags: frontend ui ux css layout css-alignment padding margin

Learned on: April 19, 2024 Edit

CSS changes not reflected (Asset Pipeline/Cache/HTML issue)

Issue: CSS changes I added to application.css for form styling were not reflected in the browser despite server restarts and hard refreshes.
Troubleshooting Steps: I verified CSS file content. Checked browser Network tab (saw 200 OK (from memory cache), indicating stale cache). Ran rbenv exec rails assets:clobber and restarted/refreshed; still no change. Verified stylesheet_link_tag in layout. Verified asset pipeline gem (propshaft). Checked for potential Procfile.dev/manifest.js issues (none found/needed for Propshaft dev). Re-inspected CSS/HTML.
Resolution: I found that the required HTML structure changes (adding classes like form-container, form-group, placeholders) in _form.html.erb were missing/had been reverted. Re-applying the necessary HTML changes resolved the issue.
Learning: When CSS doesn't apply as expected, I learned to double-check *both* the CSS *and* the HTML structure it targets. Asset pipeline issues (caching) can occur, but often the root cause is simpler: the HTML/CSS edits weren't applied correctly or completely in the first place. rails assets:clobber is a key tool for suspected CSS/JS caching issues in development. Propshaft in development typically serves assets directly without complex manifests.

Tags: frontend css debugging asset-pipeline propshaft cache html workflow assets clobber

Learned on: April 19, 2024 Edit

Task: Refine 'Log New Learning' form UI/UX

Task: Refine the UI/UX of the "Log New Learning" form (learnings/_form.html.erb) to align with 37signals principles (better spacing, guidance, alignment, font consistency).
Details: I focused on using standard Rails helpers, hand-crafted CSS, and HTML attributes (placeholder) for clear guidance, consistent spacing/fonts, and alignment with the index page layout. I used the _form.html.erb partial.
Learning: Good form UI involves clear labels, helpful placeholders, logical grouping (.form-group), consistent spacing/typography, and alignment with surrounding page elements. Using partials for DRY forms is good practice.

Tags: frontend ui ux css html rails view form form_with partial 37signals

Learned on: April 19, 2024 Edit

Visual inconsistency between `<a>` link and `<input type='submit'` button

Issue: "Log New Learning" link (<a> styled as button) and "Delete Selected" button (<input type="submit">) had slightly different heights/widths despite sharing similar CSS class (.button).
Resolution: I added explicit box-sizing: border-box;, line-height: 1.5;, and vertical-align: middle; to the shared CSS rule targeting both .button and input[type="submit"].
Learning: I learned that link tags (<a>) and submit inputs (<input type="submit">) can have slightly different default browser rendering regarding padding inclusion (box-sizing), line height, and vertical alignment. Explicitly setting these properties in CSS ensures visual consistency when styling different HTML element types to look like buttons.

Tags: frontend ui ux css html css-alignment button form box-sizing

Learned on: April 19, 2024 Edit

Stimulus controller not executing (dynamic button disable)

Issue: Despite seemingly correct Stimulus controller (selection_controller.js) setup, HTML attributes (data-controller, data-action, data-target), and CSS, the "Delete Selected" button remained disabled even when I checked items.
Context: Extensive troubleshooting performed: Verified controller registration (stimulus:manifest:update, controllers/index.js), javascript_importmap_tags in layout, controllers/application.js initialization. Added console.log statements; logs did not appear in the browser console, indicating the controller code was not executing. Tested moving data-controller scope. Checked for conflicts/errors.
Resolution: Due to the inability to diagnose why the Stimulus controller wasn't connecting/executing, I reverted the dynamic disabling feature for simplicity. I deleted the controller file, removed the registration, cleaned the data- attributes from view/layout, and removed CSS styles.
Learning: If JavaScript behavior (especially Stimulus) fails without obvious errors after checking standard setup (loading, registration, attributes, initialization, console logs), I learned to consider potential deeper issues: asset pipeline problems, JS bundling errors (check network tab/console thoroughly), subtle DOM interactions (e.g., Turbo Frames replacing elements Stimulus was connected to), typos in data- attributes or controller identifiers, or timing issues. Sometimes reverting to a simpler solution is pragmatic if debugging proves too complex or time-consuming for the feature's value.

Tags: frontend javascript stimulus hotwire debugging asset-pipeline turbo dom error

Learned on: April 19, 2024 Edit

Incorrect element movement broke layout (`form_with`/Turbo)

Task: Move "Delete Selected" button to top, next to "Log New Learning".
Issue: Initial attempt incorrectly moved the entire learnings list (which was inside the form_with) along with the button form, breaking the layout significantly.
Resolution: I reverted the changes and restructured the view (learnings/index.html.erb). I moved only the submit button (<input type="submit">) into the top .actions div. Then, I ensured the main form_with tag wrapped the entire area containing both the actions/button *and* the list with checkboxes.
Learning: I learned to be careful when moving elements within complex form structures (form_with), especially those interacting with Turbo Frames or Streams. I need to ensure only the intended element is relocated and that the form still correctly encompasses all necessary inputs (checkboxes, submit button). Incorrect nesting can break form submission or layout.

Tags: frontend ui ux layout html css rails view form_with turbo

Learned on: April 19, 2024 Edit

Deployed changes (Edit link) not appearing on Render

Context: A newly added "Edit" link for learnings appeared locally but not on my deployed Render application, despite logs showing the correct commit deployed and server restarted.
Resolution: I modified the Build Command in Render settings. I changed the order of asset tasks from ...; bundle exec rake assets:precompile; bundle exec rake assets:clean; ... to ...; bundle exec rake assets:clean; bundle exec rake assets:precompile; .... Redeploying with clean before precompile made the link appear.
Learning: The order of asset pipeline tasks in the build command matters, especially with tools like Sprockets or Propshaft. I learned that running assets:clean *before* assets:precompile ensures that stale or conflicting assets from previous builds are removed before new ones are generated. This prevents potential issues where old assets (CSS, JS) might be served by the CDN or web server, causing new code changes or UI elements not to appear as expected in the production environment.

Tags: deployment-ci frontend workflow

Learned on: April 19, 2024 Edit

Clarification: Use `./bin/dev` not `rbenv exec bin/dev`

Context: I clarified in README.md that ./bin/dev is the preferred command to start the development server, after confirming rbenv exec bin/dev causes issues (previously logged Apr 8 & Apr 13).
Resolution: I updated README.md to reflect ./bin/dev as the primary command and added a note about specifying the PORT environment variable if needed (e.g., PORT=8000 ./bin/dev).
Learning: I learned to ensure documentation (README.md, PLANNING.md) accurately reflects the working commands discovered during troubleshooting and development, including common variations like specifying a port or necessary environment variables. Keeping documentation consistent with learned best practices for my specific project environment is important.

Tags: workflow documentation readme rbenv bin/dev environment-setup

Learned on: April 15, 2024 Edit

`FactoryBot::DuplicateDefinitionError` on dev server startup

Context: My development server (./bin/dev) failed to boot, reporting FactoryBot::DuplicateDefinitionError: Factory already registered: learning.
Cause: The factory_bot_rails gem was included in the group :development, :test do block in the Gemfile. This caused FactoryBot's Railtie to load factory definitions (spec/factories/*.rb) during development environment initialization (e.g., via Spring or initial boot), potentially conflicting with other initializers or running twice.
Resolution: I moved gem "factory_bot_rails" exclusively to the group :test do block in the Gemfile and ran rbenv exec bundle install.
Learning: I learned that gems intended solely for testing (like factory_bot_rails, shoulda-matchers, capybara) should typically only be included in the :test group in the Gemfile. Including them in :development can lead to unexpected behavior, errors during server startup, or unnecessary loading as their initializers might run inappropriately or cause conflicts.

Tags: testing dependencies factorybot gemfile environment-setup workflow

Learned on: April 15, 2024 Edit

Render: Running initial migrations on free tier (Build Command workaround)

Context: I needed to run initial database migrations (rails db:migrate) on Render's free tier, which lacks Shell access or explicit Pre-Deploy/Post-Deploy command support. Migrations must run after the code is deployed and dependencies installed but before the server starts taking requests based on the new schema.
Resolution (Workaround): I temporarily added bundle exec rails db:migrate to the *end* of the Build Command in Render settings for the first successful deployment (e.g., bundle install; bundle exec rails assets:precompile; bundle exec rails db:migrate).
Learning: On restricted environments (like PaaS free tiers), essential post-deploy tasks like database migrations might need temporary workarounds, such as including them at the end of the build command. I learned to remember to remove the migration step from the build command after the first successful run to avoid unnecessary migrations on subsequent deploys and potentially slow down builds. Considering using release phase tasks if the platform supports them (Render paid tiers do) is a good idea for the future.

Tags: deployment-ci database migration workflow