Tag: tools

These 2 Apps made My LLM-Based Dev Environment awesome

Over a year has passed since my last post about using Large Language Models (LLMs) for development. I’ve gone from forcing myself to like the new tools emerging from the GPT Revolution to, now, loving my set up. The two tools I always have up while building are Perplexity and Cursor.

Perplexity.ai

Perplexity AI leverages Retrieval-Augmented Generation (RAG) to provide up-to-date and accurate information. This is especially useful when development relies upon recently released documentation or versions. My “rubber duck” is AI, and it surpasses my human counter parts, and my own ability to google for best practices and implementation guidance. It helps me crash course on new topics, or help me understand errors or issues that may span across multiple platforms in my stack.

Cursor.com

Cursor.com’s IDE offers multi-file editing capabilities. I have yet to find any product come close to it, and waited longingly for it to arrive. It significantly streamlines coding workflows, especially for tasks like refactoring where breaking up files and re-inserting blocks of code can be arduous without it. The Composer feature allows developers to make changes across multiple files simultaneously, presenting diffs in a familiar format in each file with explanations in the chat window. This SIGNIFICANTLY beats out Microsoft Co-Pilot which still feels like a hyped up autocomplete, and I find it more expansive in its capabilities than competitors like Codeium. I see Cursor as “State of the Art”, and Best-in-Class, hands down.

One of Cursor’s strengths is its use of Visual Studio Code (VSCode) as the underlying interface. Although wrapped as the “Cursor App”, it retains all the functionality of VSCode; and doesn’t leave me wanting. Initially, I was wary of adopting a new IDE instead of installing an integration into my existing VSCode app, but this skepticism wore off quickly as I experienced the seamless blend of familiar VSCode features with Cursor’s innovative AI-powered capabilities.

Key features of Composer include:

  • Editing multiple files at once by referencing them with the # symbol
  • Viewing suggested code changes across files before applying them
  • Side-by-side comparison of proposed changes
  • Creating new files as part of larger code modifications
  • Leveraging AI that understands the entire codebase context for relevant edits

Cursor maintains an indexed representation of the full codebase, enabling contextually appropriate suggestions even for complex refactoring tasks. This allows developers to describe high-level changes and have Cursor generate code that fits seamlessly into the existing project structure and coding patterns.

In practice, Cursor shows all necessary changes as diffs in multiple locations with one action, allowing review and acceptance. It even understands developer preferences demonstrated throughout the existing code base (even if not in the immediate file being worked on), such as using twMerge for className merging, without explicit instructions (as shown in the screenshot above).

Another exceptional feature is Cursor’s ability to recognize intent throughout a file when a single change is made. It proactively suggests updates to the rest of the code in a non-distracting way, and only when multiple tab taps are made. For instance, changing a typedef in one location prompts reviews and suggestions for implementing the change elsewhere with impressive accuracy.

The trust I’ve developed in Cursor’s updates and suggestions has been a game-changer. I often find myself hinting to Cursor’s prompts as a primary development method instead of coding myself. It isn’t 100% there yet, but multiple factors beyond my interest in doing so with competitor products. When I’m unable to use Cursor, I genuinely miss it.

This shift in my setup with AI-assisted development tools represents a significant change to what I was using months ago. I am not trying to leverage the tools, or impressed in the concept, but truly experiencing an evolution in my development experience that yeilds continued moment-by-moment results. We have finally broken through the hype!

Team City Monitor (with coverage history) for GAE

Per my last post about the splendor of GAE, below is one example of a tool I built for us at Socialize to keep an eye on code coverage and lets the group know if a build is broken (if our tests have failed.) This script is built to run on Google AppEngine, checks against a TeamCity Server install, and expects that each project in team city has code coverage outputted to its artifacts folder.

What is C.I. Server and why is it important?

C.I. stand for Continuous Integration, and is a system used to constantly/”continuously” checks to see if a code base is “working” or not. Team City (by JetBrains) is a product made for that process. Usually it is used to run tests against a code base to make sure it is working as expected, as a part of the QA life cycle. These tests are made up of “unit tests” that are created by the developers whom write code to test the code they are writing. It can be a bit odd for those that have not ever done so, but it is quite important when trying to deliver stable code. In short, and in its simplest form, this whole system makes sure new code/changes doesn’t break old code already in place. You can read more about these processes and purposes here: Unit Testing & Integration Testing.

What is code coverage, and why is it important?

Code coverage examines how much of your code is being tested. For instance, you may have a C.I. system in place, and a unit test frame work running within it, but if the tests only test/”cover” 1% of all of the code you aren’t really delivering a level of confidence you should be. In this tool we track the coverage percentage over time. Seeing it as a graph helps recognize dips in coverage easily.


Download Team City Monitor for GAE


Or fork and contribute on GitHub

Leave the caves and create your tools!

GAE offers a free to get started approach, along with an instant “hello word” initial environment, making sandboxing ideas and building helpful tools for productivuty a snap.

To get started, download GAE, press the plus sign in the bottom left corner. Set the directory you would like to work out of and your almost done. Well, at least you are already at the stage you need to be to start playing with the system locally, in what we call the development environment (No one can see your system but you.) Just hit the [play] button on the GAE dashboard and you are running with your first environment. Just click the Browser (the compass looking thing), or go to http://localhost:8080 in your browser, and you should see your first “hello word“! It is quite reassuring to see it work so smoothly (if indeed it does), and if this is the first time you have coded, trust me they have taken out a hell of allot of pain out of the tedium it can take to get here.

Without getting into the nitty gritty of code just yet, let’s push your baby to production (That means make it live/accessible to the world). That’s right, you are about to push a web application live to production!  First create a new app at the google app engine home page and follow the steps there (setting up your yaml for upload). Your yaml file tells google which app your are updating when you do so. Not making sure your yaml matches your project is like  you sending mail through the USPS without out a “from”/”to” address.

Once complete, press the blue arrow pointing upward (the “deploy” button) and it will deploy (AKA: push to prod, go live.)

Once deployed, you can update, monitor, or even share you application with the world. And all for free. Not that this baby would get allot of attention in its current state (just a “hello world”), but if it did, it would also be scalable. I mean 10 years ago this would have cost you quite a bit of time money, especially if you didnt know allot about server configurations, apache, linux, or windows server, or…well you get the idea.

There are a few sample apps you can play with on the GAE site. If you are ready, start developing some code i Python. Maybe had a hellow world message of your own.

When you start feeling saucy, try and create a model. A model is a data structure you can save, or persist, data to your system. Again to you newbies out there, this is the equivelent of your granfather telling you, “back in my day I had to walk up a hill in the snow to get to work, and up a hill in a blizzard to get back.” Setting up a database on a production server was a skill on its own, but to create one that is scalable, and without the need to architect it is amazing. You see, based on the models you create GAE intuitivley creates your “database”, stores it efficiently, and assumes where indexes need to be placed. You really don’t have to understand any of this, but if you want to you can look up those terms have at it: indexing, database, architecture, MVC…. Like I said, I’m just an old guy complaining about hills.

If you are still a bit timid about getting started, don’t worry there is a baby step in between these tween sized steps that can help you get ramped up before you start churning out lines and lines of code. Click on the “SDK Console” button on the GAE dashboard. It will open up a web page that is running locally, on your stage environment, that gives you windows into your system to hack around with. (This console lives inside your development app, so don’t forget to run your new app to get access to it.) Once in the console, click “Interactive Console”. There you will have a very rudimentary terminal that you can write temporary test scripts in. The output is shown on the right of the screen. This is a great place to get errors, make mistakes, and go nuts! (Note: The SDK Console also houses your development DB, so you can check to see what data you are saving after you have attempted to save it.)

Note: The easiest way to get started as a newbie, in my mind, is by using Python in GAE. Java, although awesome, is a bit more advanced.

I recently used GAE to create a few projects to help out the team. One for TeamCity monitor to view coverage reports and if a build is broken or not. And also one for Pivatol Tracker to help our press and marketing interpret what is coming out of the product pipeline, if its ready, and what are the stories of value within. I will post templates for those projects in the near future.