I had the pleasure of attending Google Cloud Next 2024 and while it comes as no surprise that Generative AI was a huge part, it was by no means the only exciting part of the event. With that said, I wanted to take some time to record some highlights as it was also my first in person event in my new role as a Strategic Cloud Architect at CDW and Google’s most attended Cloud Next event yet.

If you’re running Kubernetes you really should be using Horizontal Pod Autoscalers (HPAs) too. They work by continuously monitoring the resource usage of a deployment, replicaset, or other scalable resource, and automatically adjusting the number of replicas (pods) based on the defined scaling policies and metrics.

In the context of MLOps and Langchain, agents can incorporate the RAG (Retrieval-Augmented Generation) approach to enhance their capabilities. RAG involves retrieving relevant information from external sources (e.g., databases, knowledge bases, or web searches) and using it to augment the input to a language model, improving the model’s ability to generate accurate and factual responses.

Machine learning has become the cornerstone of innovation across industries, propelling advancements and unlocking new possibilities. Yet, the orchestration and management of ML workflows often pose significant infrastructure challenges. Enter Kubernetes and Kubeflow, two powerful tools revolutionizing the landscape of machine learning.

In the world of managing services, Service Level Indicators (SLIs) stand as the cornerstone of measuring performance and maintaining quality. They serve as the foundation upon which Service Level Objectives (SLOs) and Service Level Agreements (SLAs) are built, delineating what to measure, how to measure it, and the consequences of falling short.

Being a full-stack developer means we have a lot of things to focus on in order to build a successful application. With so much evolution happening on the front-end, a lot of developers have drifted away from the back-end and dev-ops… that’s where MongoDB Atlas and Stitch comes in. MongoDB Atlas is a Database as a Service (DBaaS) that backs Stitch, their Backend as a Service (BaaS). Today I’m going to show how we can interact with MongoDB from our front-end logic without having to spin up an API! The React application we’ll be using can be found here.

Chances are if you’re a web developer you’re going to have to write some CSS from time to time. When you first looked at CSS it probably seemed like a breeze. You added some border here, changed some colors there. JavaScript was the hard part of front end development! Somewhere during your progression as a front end developer that changed though! What’s worse is that many developers in the front end community have simply learned to dismiss CSS as a toy language. The truth however is that when we hit a wall many of us don’t actually understand what our CSS is doing under the hood!

Mistakes happen. It’s a fact of life. In fact, mistakes are often a precursor to growth... as long as you learn from them! Occasionally at work, our support team receives feedback from customers trying to sign up for one of our paid tiers, explaining that the transaction failed. Not only does that stink for our customers, but it was a pain point for us. We integrate with a third party for payments, that at times responds to a request with what’s essentially an unknown error. In most cases we’re able to surface a helpful error to the user based on logic that parses the response. But up until a few months ago, we had zero visibility into the unknown errors. We had no way to help our customers, and no way to learn from the problem! After looking at a few more third party solutions, we decided to leverage functionality our current stack already provided.

Some updates to our Angular-based UI and our Nginx web server was all it took. And while we were at it, we went ahead and used the approach to log uncaught exceptions too. In the UI, we built a simple service for posting errors to Nginx. We just have to get the username from the session, along with the error response and data posted, (of course, for compliance reasons, we never deal with credit card information, our third party services takes care of that) and post it back to our logs. No need to catch a rejected promise in the service either, because for our case, we don’t have a need for handling failed log attempts.

Now that I'm working on a larger code base, debugging has become increasingly important and complex. With that said, I decided to dig into some documentation, and explore how I can use tools that already exist more productively. Below are some of the tricks I've come up with so far.

Chrome Dev Tools

Console:

January 6th, 2014 seems like yesterday. Looking back though, I'm utterly amazed at what I've been able to accomplish in the past 12.5 weeks. The 'Front End' course at the Nashville Software School does indeed cover the 'front end'. However, within a few short weeks we were covering much more than basic JavaScipt and jQuery. From week 5 on, we used JavsScript on the full stack via Node.js. With that said, I wanted to take a short breather before the final three months of Ruby and Rails to reflect on everything I've learned while completing the first half of my six month program.

Weeks 1-4

To our surprise, day one started off with us opening up Vim. Our instructor, who previously taught at both General Assembly and the Flat Iron School, drilled home that 'real programmers' don't point and click. From there, we rounded out the first month with lots of  linux, HTML and Jade, CSS and Less, JavaScipt and jQuery, Ajax, Git, Pair Programming, some logic puzzles, OOP, TDD with QUnit, JShint, Grunt, and of course Tmux.

Weeks 5-8

Somewhere around the 5th week, we had our first 'exam', which split our class into the Alpha and Beta groups. The Beta group ended up perfecting their front end skills, while the Alpha group dove into Node.js. Along with Node, we covered Express.js, MongoDB, TDD and BDD with Mocha and Chi, and deployed our first apps to an Amazon Web Services (AWS) Elastic Cloud Instance (EC2).

Weeks 9-12

Thoroughly exhausted, week nine started us on our back to back, to back, to back, to back, Hackathon weekends. In other words, we had group projects, and our final two capstones to work on each weekend from here on out. And by group projects and capstones, I mean I was programming at least 15 hours a day seven days a week. In regards to classroom lecture, we covered Socket.IO, Travis CI, Coveralls (ensuring code coverage), Gemnasium, and more advanced Git topics.

All that to say, I've become a huge fan of JavaScript and Node.js. Although the learning curve was much steeper than when I first began teaching myself Rails, the flexibility that Node provides completely won me over. As I embarked on my capstone projects, I was able to bring together everything I'd learned about asynchronous programming, and the pipeline in Node to completely customize my apps. One highlight being that I was able to integrate my own authentication alongside OAuth, all with TDD in mind. Something a bit more complex than what I'd done before in Rails.

So, that's roughly three months down, and three months to go. With Node.js being relatively new, I hope to be able to write additional posts on some of the more specific topics I was able integrate into my projects. Specifically, as time allows I plan to thoroughly discuss Passport OAuth and Stripe in Node.js. Especially, since Passport and adequate TDD proved to be a bit of an initial pain point for me on my capstones. In the meantime, feel free to checkout my final project on GitHub. https://github.com/AimeeKnight/Civic311

I'm pleased to report that my decision to begin the Nashville Software School's fourth cohort has been a wise one. I'm currently four weeks in to the first half of the program, and although intense, I'm loving each and every moment. We're snowed in today, so I'm going to write a brief post in place of my usual commute time.

Up until this week, I'd understood closures only at face value... I could explain what they were, but hadn't reached the point of knowing how to really utilize them in my code. So, I want to record some notes explaining how they work, and an instance for using them effectively.

Every function, comes with an associated environment. JavaScript Allonge states this wonderfully; "Every time a function is invoked, a new environment is created. The "x" in a expression that we call a “variable” is itself an expression that is evaluated by looking up the value in the environment." When you define a function, within another function, the inner function's environment, also includes the outer function's environment.

Closures in JavaScript also mean that a functions variable values are set when the function is called... not when it's defined. With loops, this can get tricky! I've added some additional comments to the snippet below from Mark Story's blog explaining how this works. Essentially, we first define a function "clicker". Then, we call clicker within our loop to create a closure which captures each number, and ensures our event listener is set according to i's current iteration value.

I prefer to keep my posts technical, but I'll deviate from that for a moment to talk about my decision to attend the Nashville Software School (NSS).

Growing up as an athlete, I found that with enough grit, I really was able to accomplish whatever I had my sights on. However, with 'coding bootcamps' popping up left and right, I was drawn to the idea of being able to reach my goals faster, through an intense, immersive experience. With programming being quite possibly the largest rabbit hole known to man, I think the biggest benefit for me with be having a structured curriculum to follow.

A word of advice for anyone who may also be considering attending one of the many bootcamps out there. These programs are NOT all created equal. Specifically, I wonder how much you can really teach someone in a 10-12 week time span. The shorter programs that are successful, are filled with people who've already got a good bit of programming  experience under their belt for that specific reason. Not to mention, I think it's important to have a solid 6-12 months exposure to the field before deciding whether or not a bootcamp is a wise investment for yourself. Personally, it seems a bit far fetched to think you can take someone who's done a few weeks worth of pre-work, and have them ready for a substantial job offer in that kind of time frame. Even with 18 months experience teaching myself, and pursuing a second Bachelor's in IT, I declined slots at other programs and decided to look at gSchool and NSS, both of which are 6 month programs. During gSchool's Skype open house, it seemed my concerns were shared by a lot of other prospective students, many of which had also declined their slots. With NSS being a non-profit, and with my family 70 miles away, I accepted an offer from NSS without moving further with my gSchool application.

Finally, I'll add that this is only the beginning, a next chapter as it may. Once I complete NSS, I will be continuing on with school, even if it means continuing at night while working. I  want to dig deeper into some lower level languages, and while others may see formal education as being unnecessary, I definitely don't see the harm in utilizing every resource available.

Feel free to ping me if you have any specific questions about some of the other programs. I'd be glad to share more about my experience, and point those interested in a good direction!

As an aspiring full stack developer, I spend a lot of time in terminal (iTerm2 specifically). In fact, I actually prefer to work in terminal rather that with the OS X gui. With that said, I want to share some of the things I've learned in regards to customizing your bash prompt.

First up try this;

$ env

The env command is going to dump your current bash session's environment variables. Right now, since the focus is on customizing our prompt, we're focused on PS1 which stands for Prompt String One. Likely, PS1 will be set to a default resembling \h:\W \u$. Here, \h returns your computer's name. \W, returns your home directory. And \u returns the current user. Since I'm the only one on my machine, my machine's name, and my username are pretty useless. In fact, the actually clutter up prime real estate. So, for my purposes, I've chosen to only retain my working directory. For fun, I did explicitly add a name as well. (I'll post the code in a moment since I'm not done just yet.)

So, just like any variable, you can reset PS1 like this:

$ PS1="what ever you want here"

However, if you want the changes to take affect each time you start a new session you're going to need to edit your bash profile. I have sublime set up to open files from iTerm (see instructions here) so I can pull up mine for editing like so:

$ sublime .bash_profile

From there,  I simply append the following:

Simply, my thoughts recorded for future iteration.

1. $ git clone
Only needed on first cycle.

2. $ cd cloned_root_directory_name

3. $ git pull
If done immediately after 'git pull' this step isn't needed.

4. $ git checkout -b feature_branch_name

5. do some hacking

6. git add .

7. git commit -m "your message"
Repeat steps 5-7 as needed.

8. $ git checkout master

9. $ git pull
Merging the remote master repo with your local master repo should be a clean fast forward since your hacking has been contained to your feature branch.

10. $ git rebase feature_branch_name
This is where things could potentially get ugly. To prevent complicated conflict's it is recommended to repeat this often.

11. $ git push origin master
Reminder, this is meant to be a simple workflow for a small team. It is highly advisable to check if there have been any pushes to the remote master since you completed step 8.

In the fall of 2012 I received a scholarship to the Team Treehouse website.  Although my path is only beginning, I'm incredibly grateful for the  foundation their tutorials have provided me.

 Read my TreeHouse story here:

http://teamtreehouse.com/stories/aimee-knight

Context: I'm writing this as a quick reminder to myself. Sort of like when I was back in Catholic elementary school and the nuns would make us tirelessly write out our vocabulary words until our wrists were ready to fall off!

Function hoisting in JavaScript is determined based on whether you're using a function expression, or a function declaration. I'm going to let an example do the talking.

Just some notes written down for my own reference. Enjoy them if you wish!

Here's another cool trick I learned through pairing today during my apprenticeship. In IRB, you can use an underscore to retrieve your last return value. Seems like the perfect shortcut whenever you realize too late that you should have stored a value in a variable! Here's a quick example.

$ 1 + 2
=> 3
$ _ + 3
=> 6

I started an apprenticeship a week ago and I've learned an incredible amount of tricks through our pairing sessions. Side note... Screehero is the pairing app we're using and it's wonderful! Part of my task for the week was to automate the process for backing up our production database to our local machines in Ruby. By now, I'm somewhat comfortable with Ruby and terminal so separately these tasks didn't seem too bad. The challenge was to figure out how to execute bash in a Ruby script. To my surprise, this was actually MUCH easier than I was expecting. My trick, was to wrap my bash in backticks within my .rb files. I imagine this can be pretty powerful since instead of inputting endless commands in terminal, I can now simply feed it my .rb file to execute. Cheers to becoming a lazy programmer! Now if only I could get the benefits of logging 30 miles running each week with a shortcut like this!

Here my super simple Ruby script in case anyone needs some MySQL bash commands for a SQL dump.

Ever want to know what files would be generated for a specific rails generate command? I read today, that you can find this out simply by passing in a -p flag to the end of your command. Cool!

$ rails generate model myModel -p

1. Find the setting button for your app on Heroku.com
2. Edit your apps name and click 'Rename'

Next, since the directions above use the Heroku website to update the app name, and because you may have other developers contributing to your project, the individual git remotes will also need to be updated.

3. In terminal (still in your apps root directory) run:

$ git remote rm heroku

followed by

$ git remote add heroku git@heroku.com:yourappname.git

You're now good to go!

UPDATE: There is actually a much simpler way to go about renaming your app. Simply run:
heroku apps:rename newname

If you've tackled your CLI fears this is much easier as it allows you to rename your app and updates your remote Heroku repo in one.

1. mkdir -p

If the parent directories don't exist, the -p argument creates them.
Example: $ mkdir -p unitedstates/illinois/chicago

2. /

Brings you to the absolute root folder.
Example: $ cd /

3. ~

Brings you to the relative user account home folder.
Example: $ cd ~

4. pushd & popd

The pushd and popd commands work just like array methods, allowing you to easily navigate between multiple directories. If you're at your desktop, use pushd and pass it the path to chicago to change to chicago. When you want to go back to your desktop, just use popd, (without a parameter) to take chicago of the stack. You can do this for multiple folders, and it just pushes them on the end of an "array" of directories and pops them off as you need them, first in, first out. Note that pushd can also be used without a parameter to swap between directories already on the stack.
Example:
$ cd desktop
$ mkdir -p unitedstates/illinois/chicago
$ pushd unitedstates/illinois/chicago
~/desktop/unitedstates/illinois/chicago ~/desktop
$ popd
~/desktop
$ pwd
~/desktop

And for a little fun I have to admit something. I have a horrible irrational fear that my cat is going to somehow walk across my laptop when I've left terminal open and type rm -rf /!

Here goes another newbie post. I’ve been told over and over again not to dig into Rails 4 yet since there’s not a lot of info out there. But, if I’m learning Rails for the first time, doesn’t it make sense to hash out the differences and not develop habits that are going to be depreciated? So now, I’ve set up my environment so I can have the best of both worlds!

In my newness, I’ve unfortunately allowed a slew of gems in my default gemset which makes things messy when you want to work with various versions of Ruby and or Rails depending on your app. My solution going forward is to create .rvmc files per app (or groups of apps), that will contain custom gemsets so I’m not polluting my default environment. This is best done with a clean (or minimally polluted default gemset), but works fine if you’re like me and already have Rails 3.2.X set as your default.

If you already have RVM installed, go ahead and get the latest version. In terminal run

$ rvm get stable –-autolibs=enable

The --autolibs flag tells rvm to automatically install necessary dependancies on you system as well (important for those of us still with student status)!

From there, you can check for any Ruby updates you want by running

$ rvm list known

Since Rails 5, (gasp, I’m still trying to learn 3.2 and 4) will require 2.0, I figured I might as well get going with that!

To install run

$ rvm install 2.0.0

Of course you can explicitly use any version returned from the known list also.

Now for the fun stuff (many thanks to Kevin Lawver from Rails Machine for helping me with this part)!
In terminal, cd into whichever directory you keep your rails projects, create a new directory for Rails 4, then cd into that one.

$ cd rails_projects
$ mkdir rails_4
$ cd rails_4

From there, you’ll create a directory specific gemset. I’ve explicitly stated I want to use Ruby 2.0.0, but of course you can choose whichever version you like.

rvm –-rvmrc –-create 2.0.0@rails_4

Cd out of that directory, and then cd back in. It will ask you to accept the new .rvmc file which you will of course say yes to.

$ cd ..
$ cd rails_4

For extra assurance you can run

$ ls –a

to see the hidden .rvmc file.
Then, all that’s left to do is to install Rails 4. Don't panic... it may take a few minutes.

$ gem install Rails

Followed by

$ gem install bundler

You can now run

$ rails new myApp

To generate you Rails 4 app.

Update:

I recently made the switch over to SparkPost, which is one of Heroku’s newest add-ons (I also work there)! There is a free basic plan that includes up to 10K of emails a month. SparkPost has the highest inbox placement of any provider, and real-time analytics with over 40 different metrics. It's also built by Message Systems, which is the email provider for large scale companies like Facebook, Twitter, and Pinterest, so that made migration an easy choice! The move was straight forward, quick, and easy!

Once you have a card on file, just run
heroku addons:create sparkpost:free
to add SparkPost to your app.

I'm going to write this from the standpoint of where I was last week so here's some background. I, like many other newbies was happily going along completing various Rails Tutorials not aware that my "secret token" was being committed to my public GitHub repo for the world to see. For random tutorials this isn't really a problem, but when it's time to start an actual app you plan to deploy, then this is going to be necessary. The solution... environment variables. There are a ton of ways to go about hiding your apps token (and other confidential info like emails and passwords), but I opted for Figaro.

Configuration is pretty straight forward. Add Figaro to your Gemfile and run
$ bundle install

followed by
$ rails generate figaro:install

Figaro's generate command will create an application.yml file for you and automatically add it to your .gitignore!

Now, add the variables you want hidden into config/application.yml.
It will look something like this if you use Gmail:

I've been meaning to write my first blog post, but have a hard time stepping away from my own learning for a moment to share something I've learned. With that said, this is going to be short and sweet (but hopefully prevent some headaches)!

There seems to be some inconsistency between the development and production environments with how the Twitter Bootstrap Rails gem is being handled in the Rails Javascript manifest file. The solution I've come up with (thanks to some help from Stackoverflow) is simple.

In development, make sure you're including bootstrap first!