DEV Community: ben

CharacterDex (DEV Education Track: Build Apps with Google AI Studio)

ben — Fri, 04 Jul 2025 13:33:37 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

Let's build an app like a Pokédex, but for fictional book or film characters!

Use Imagen for their photo and Gemini for their name, profile, short backstory, etc.

Wrap it in an app that lists human / animal / object / etc. categories or filters.

Let's pre-populate a dozen characters, if possible.

Demo

https://character-dex-369102945670.us-west1.run.app/

My Experience

I'm completely blown away! What would normally be a week's work, Google AI completed in a matter of seconds. I needed one tweak to make sure the images were stored and working correctly, but otherwise it was out-of-the-box.

What's the difference between a Rails application and a Rails API ?

ben — Tue, 25 Feb 2020 12:23:58 +0000

Ruby on Rails provides the new command to create a web application; there's also the --api option available for creating an API application, which won't need much of the frontend capabilities that a full-stack application would.

You may wonder why Rails is still a good choice for an API, which are supposed to be lightweight and machine-orientated rather than comfortable and human-orientated. The answer given by Rails Guides may resonate with anyone that has developed a Ruby application of a decent size without using Rails or other frameworks:

You may not have thought about which parts of Rails are still applicable even if you remove the view layer, but the answer turns out to be most of it.

The features highlighted include:

tools like Rack and the Rails Router to handle the HTTP layer smoothly
configuration and integration of database connections
dynamically generating URLs for resources
caching, at various levels
authentication
instrumentation, both within Rails and from integrated, third-party tools
auto re-loading
multi-environment configuration

There's a lot that a Rails API can offer over a plain Ruby alternative! Some frameworks are built for lighter web and/or API applications, but here we're going to concentrate on the two Rails offerings.

What are the differences? 🔍

Rails Guides describes the API application as:

[a] Rails application that serves JSON resources to an API client, including client-side frameworks.

I've put together a Git repository to demonstrate:

commit 6ced3f81 shows what a new API application looks like
commit 4d52ac32 shows what a new web application looks like
commit 04db2c29 shows the difference between a web and an API application
commit 2665ded0 shows the difference between an API and a web application

The last two are of course simply opposites, but this provides a useful guide for converting one into the other.

Let's take a look inside the commits to see what differences there are between the web and API applications!

Gems 💎

This may not be surprising, but there were the assets-related gems removed, and a hint for some CORS support added. Without the frontend driven by a browser, there's no use for the web-console, nor testing with capybara and friends.

Configuration ⚙️

Rails API applications are very similar to the full web counterpart. A noticeable difference is how individual components are specified in the application's boot sequence.

the main change is, of course, enabling Rails::Application#api_only to trigger some changes to the internals, like skipping sessions and cookies support unless otherwise required.

Application Layers 🔗

Following the removal from the Gemfile, the app/assets directory is removed. There is no need for a layout nor the public pages, as the controllers given an unfulfillable request will serve the 404/422/500 HTTP status, perhaps with the error in a plain-text body content or none at all.

The documentation shows how the main controller differs:

inside app/controllers/application_controller.rb, instead of:
class ApplicationController < ActionController::Base
end
do:
class ApplicationController < ActionController::API
end

I'm not sure what impact this has, as we haven't built anything on top of the application scaffold. Maybe this can be an exploration to take in another post!

Testing ✅

It interested me that the MiniTest scaffolding was not present in a Rails API application. I presume this is to allow complete freedom for the developers, or the Rails team didn't agree on a default!

Thanks For Reading! ❤️

I hope you've enjoyed exploring what impact the innocuous --api flag can have on a new Rails application!

Have you started with a Rails-based API and moved it to a full web application, or vice-versa? Do you consider Rails for API applications, or prefer other approaches? Let me know in the comments below!

This Week In Work #4

ben — Fri, 05 Jul 2019 18:16:26 +0000

It's seemed easier to write these weekly reviews when there have been fewer happenings; the last few weeks have been more fast-paced. It's an interesting thought that having more things to write makes it more difficult.

To break the paralysis, I hope to pick out a few events.

Conferring

I'll write up something separately, but today was the annual Brighton Ruby conference. My company only had myself attend this year but we have had up to a dozen make the journey along the south coast.

While I caught up with a few ex-colleagues the vast majority of my time was spent on my own, so I think for future events my attendance will depend on being in a group.

Conclusion

I enjoy the talks at these events but I'm not a networker. There's something about being there, though. We encourage anyone in the company to go to events -- I'll shout about it more next time!

Diving into the Unknown

Back-story: someone wrote some code. In fact, they wrote lots of important code, and it was good. In the interest of knowledge sharing, an improvement was given to the team to pick up rather than the original implementer.

The change wasn't complex: ingest some data and update our copy, shuffling the format a little on the way.

Wonderfully, I didn't need to talk with them to change their code: I could rely on their tests to prove my "happy path" would work. Moreover, the code was layered in such a way that meant it was easy to change. This wasn't by accident. We knew that further ingestion of other parts of the available data was inevitable, so they kept that area simple and segmented.

Conclusion

Change is not easy, but we can make it easier. Of course, write useful tests; that helps everyone that sees your code. You can help further by restraining yourself from adding just in case features: instead leave it right before you add anything that's not necessary. You'll leave a clear place to start work next time, whether that's by you or your colleagues.

This Week In Work #3

ben — Fri, 14 Jun 2019 14:15:24 +0000

It seems a tradition to say that this was last time:

This Week In Work #2

ben ・ May 2 '19 ・ 2 min read

#review #weeklyreview #weeklyretro

I've recently been on holiday with my family and had a week-long trip visiting our biggest client, so you had to wait to hear what I've been paid to do this week.

Ready to Launch!

We've been working towards the launch of the project that I'm leading! I've made sure to keep up the documentation and meeting minutes so everyone listening can shout out as early as possible.

Both parties have accepted some shortcomings, and - importantly - backed-up by numbers, so we can launch our MVP quicker. It's great to have a cross-company team that wants to learn and iterate!

Conclusion

It's just as important to keep focussed on the why at the start of a project as it is through to the end. Don't be afraid to let something change before launch, if it is important enough.

Breathing Space

It's been refreshing to wind-down for a few hours by working on a side-project. I'm deliberately using different designs and software patterns to what I'd normally do, in a more hands-on approach to reading books. I tend to appreciate the differences and side-effects more, this way. I hope to share more as the product takes shape, though to some it might be interesting already!

Conclusion

Professional development doesn't have to be academic, like reading thick books or writing proposals or reports. A company that trusts their colleagues won't complain if they are spending a small amount of time building things for themselves - competition clauses apply, of course! It's important to use that time to stretch yourself, as you've got the safety of being able to throw it away without costing your employer too much money.

This Week In Work #2

ben — Thu, 02 May 2019 16:48:52 +0000

Publishing my first weekly review gave me such a great feeling that I'm doing it again!

This Week In Work #1

ben ・ Apr 26 '19 ・ 4 min read

#review #weeklyreview #weeklyretro

Although it's been short, it's been good; here's what I've been paid to do this week.

Leading Projects!

We're starting a project with our biggest client, and for the first time since becoming a senior developer, I've been the opportunity to lead our part! It's been great so far!

I've made sure that we have made as much documentation as possible, and that it is as useful as possible. This means clearly explaining the why as well as the what, starting high-level before exploring the details, and making sure to identify the relationships between things as we build up the picture.

Conclusion

Start as we mean to go on, and keep going! You're not really doing the design and documentation for you, it's for your team, present, and future.

Exploring Dark Corners

... of our technology stack!

I think this can be summarised with one fact:

The documentation doesn't go as far back as the (pre-1.0) version we're using.

I've needed to add a few things to an existing application, but also implement a whole new process. This means understanding where and what the moving parts are, so I can find out how to create my stuff correctly. There's probably one person I can ask for help, but it is, unsurprisingly, years since they been have actively involved with the code that they would also have to search for documentation and examples.

It's been fun to dive into a framework, not so fun having to guess what is the correct way to do it!

Conclusion

Maintainability is a key part of software development, and tackling technical debt always pays off. Sometimes it's tough to take the big hits, like major version upgrades, re-writes or even re-builds, but there will come a time to do it. Make it easier by doing it often.

When working with older software, make sure others know about how painful it is, how much longer it's taking, and how it's not just a great thing we should do. Make sure to either incorporate technical debt into the regular work cycle, or dedicate a block of time to tackle it. I'd rather tasks be easier, more fun, and take less time.

This Week In Work #1

ben — Fri, 26 Apr 2019 15:22:52 +0000

A week of ~~frustrations~~ challenges in my day job have lead me to keep a journal of them, to give me time to reflect on what's going on. This is the first of (m)any entries.

Some context to my current professional role:

Our teams revolve around a web application and some supporting services, such as product creation and the storage of customers' assets. The service, which I refer to as a whole, started life over ten years ago and still does essentially the same thing today. The "complications" have come about from providing various flexibilities through abstraction layers, as clients have come and gone, and the business has "grown up" quickly over the latter half of that decade.
I've been involved for the latest three, an in this year I've moved from mid-level to senior developer within the team. While most of our work is web-orientated, we don't like to think of ourselves as "web development" strictly, rather "product development/engineering" more generally.
We created an operations support team last year, essentially to act as 2nd line to the 1st line customer support. The ops team is made up of developers, infrastructure engineers, support staff and their team managers, on a weekly rotation. We are much more aware of and investing much more time in addressing production issues. It also aims to improve our tooling, but we've been too busy fixing broken things in the meantime.

Here's what I've been paid to do this week.

API Migration

My first task this week was to finish moving our application to a new version of an API. This has lasted for literally months -- the service does one thing and does it well, so few people have worked on it -- as the API provider required much more than initially documented, to the point that development, testing, and deployment was 100% successful, and that lasted a week before it 100% broke without warning. The months were spent catching up.

We didn't notice the problem directly points to a lack of monitoring/reporting; we have since expanded our monitoring, which thankfully reports no other issues.

Conclusion

For our API issues, you can't manage what you don't measure. Problems will surface that no-one has seen or predicted before. This feels difficult when working with an existing system, but the reality is that it's just progressive. Regular reviews will show the improvements.

Leading A Team Takes Time

Today, I've not progressed the "active" issues I am working on. Instead, I've been helping my colleagues with their tasks and other issues, writing very reflective things like this very thing, and various project discussions.

Both this team's leaders take a set time in the day for code review, stand-up, and everything else that is supposed to happen alongside everything else. It might sound obvious, but it is a deliberate act. Context switching is a productivity killer, so don't do it; it only happens as a last resort.

Half an hour until a conference call, then home-time to my family.

Conclusion

The two words, "job role," mean to me the what you do, and how you do it. Today, my job has been to be the "senior" instead of a "developer" and help my team get better together. It's still been a good day. (Sorry if you were waiting on that issue.)

Ingesting Trusted Data

... some of which turn out to be wrong. We trust our commercial partner to tell us the product range, and all the messy details we don't want to know. The ingestion of that data is independent of the usage, and that's great for reliability but not so great for being able to directly tell what's caused a problem in another part of the system. You need to know what you're looking at and what you're looking for; the two are likely to be different.

I don't think the problems we have on a day-to-day basis have been getting worse. I think it's just time has just exposed it to more people, by a never-changing stream of instances. They take everyone a long time to debug, mainly due (in my opinion) to everyone having to go through the same learning to understand what's happening. Improving our tooling, for our own use, and for more people to dig into how the process is designed, would help us better understand what's going on when issues arise. As I said earlier, we've been too busy fixing the fallouts to fix the problem.

Conclusion

We considered the process as "working" by it being in production with stable influences (i.e. good data coming in, giving good outputs) and having some people (now one person) knowing the full, end-to-end process. This is, of course, not sustainable long-term; people come and go, both inside and outside the domain, so new people must be able to quickly understand what's going on.

Improving the tools we use is an on-going effort. The company is maintained by hiring when colleagues move on, so you must maintain the tools we all use. This does seem to take away from the capacity to deliver on clients' wishes, but open communication with the clients that we are hampered by a complicated, or at least a non-intuitive, system and want to improve it, will benefit us, them and our customers.