Accidental Technologist

Musings about Entrepreneurship, Technology and Software Development

  • Home
  • About
  • Still River Software
  • Privacy Policy

Powered by Genesis

Hotwire Fix for CORS Error when using Omniauth

May 13, 2021 by Rob Bazinet Leave a Comment

Tweet

I’ve been working on a small side project lately and having some fun trying some new Ruby on Rails features.

The application allows a user to authenticate using their Twitter account. I’m using the omniauth-twitter gem to implement the Twitter strategy with OmniAuth. It works great; the user is redirected to Twitter to enter their Twitter username and password then sent back to the site with a token for the user’s account.

The Problem

Everything was working great until I implement some of the HTML over the wire goodness of Hotwire.

I have a couple of areas on the site that rely on a Sidekiq and update a page when the job is complete. A perfect use case for Hotwire. The job processed, changes broadcast, and pages updated when the model changed. It worked as planned!

I deployed the update using Hotwire, tested and everything was working as I wanted. Deciding to authenticate a different Twitter account, no longer was I sent to the Twitter page to enter my credentials. No error on the page; it just did no redirect.

I looked for any errors in the Rails log. I could see the request initiated but it seemed to drop out of sight with nothing additional logged and no errors.

Maybe it’s a browser-specific issue. I usually use Firefox so I tried Chrome and Safari with the same results. Digging a bit deeper I decided to look at the Network tab in the browser to see if the request was giving an error and I found nothing. The request wasn’t going out to Twitter.

Inspecting the console in Firefox revealed this ugly message.

Access to fetch at 'https://api.twitter.com/oauth/authenticate?oauth_token=<my secret token>' (redirected from 'http://127.0.0.1:3000/auth/twitter') from origin 'http://127.0.0.1:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I started to search around for the error, and many solutions had me trying the rack-cors gem and other methods to satisfy what needed to be done. Nothing worked. I spent a couple of hours going down this path to no avail. The error is deceiving and not indicative of the real problem.

Debugging

I had done many updates since the last time I knew this worked, including gem and NPM package updates. After removing and testing each update, the message still appeared.

I determined which code was updated since the feature recently worked. I evaluated and ranked each change by how much I thought it could cause the problem. The only change that was a bit of a black box to me was the addition of Hotwire to the mix. I removed the Hotwire-rails gem and removed all the code related to Hotwire and, moved back to Turbolinks. Magically it all worked again.

Adding Hotwire caused this problem.

A Solution

Being new to Hotwire I wasn’t sure where to start. I started with what any good developer does…a Google search.

I came across some posts on the Hotwire forums and on the Devise Github issues list that provided a solution that worked. One, in particular, gave this solution:

It seems like adding

:data => {turbo: "false"}

and making my link a button seems to make it work as per: Devise github login not working after Turbo enabled. · Issue #45 · hotwired/turbo · GitHub. I now have a different error, but that it something different. So I suppose this is solved for now.

The original button I used to connect with Twitter, looked like this:

button_to "Connect a Twitter account", "/auth/twitter", method: :post, class: "btn btn-primary"

After the suggestion above, it now looks like this:

button_to "Connect a Twitter account", "/auth/twitter", method: :post, data: {turbo: "false"}, class: "btn btn-primary"

After adding the code to the button, it works as it did before. Simply don’t use Turbo for this type of request.

The Turbo docs do discuss disabling Turbo on specific links. The error I received did not do a good job of pointing me in the right direction and I spent some time going down the wrong path. I hope someone else can save some time if they have a similar problem.

Conclusion

Solving this problem was time-consuming, but I learned a bunch. Hotwire is in beta at this time. I’m sure things will improve, and maybe we don’t have to solve problems in this way in the future.

A lesson I learned is the need for some better end-to-end tests for this project. I thought since it was going to Twitter and back, it wasn’t necessary. I was wrong.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Hotwire, Ruby on Rails Tagged With: CORS, Hotwire, Omniauth

Fix Installation of Ruby using rbenv on macOS Big Sur

April 26, 2021 by Rob Bazinet Leave a Comment

Tweet

I’ve been using with rbenv to manage installation and switching of Ruby versions for the pass year and have been very happy with it. I recently took the plunge and upgraded my main Apple MacBook Pro from macOS Catalina to Big Sur. Everything seemed to work well after the upgrade. Until I tried to install a new version of Ruby.

Problem

When performing the usual command to install Ruby with rbenv, I started getting this message:

~ $ rbenv install 2.6.7
Downloading ruby-2.6.7.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.7.tar.bz2
Installing ruby-2.6.7...
ruby-build: using readline from homebrew
BUILD FAILED (macOS 11.2.3 using ruby-build 20210423)
Inspect or clean up the working tree at /var/folders/mq/tlm78wy92v54ygbzfykqc8640000gn/T/ruby-build.20210424214159.42314.u6mGui
Results logged to /var/folders/mq/tlm78wy92v54ygbzfykqc8640000gn/T/ruby-build.20210424214159.42314.log
Last 10 log lines:
        rb_native_mutex_destroy(&vm->waitpid_lock);
        ^
vm.c:2489:34: warning: expression does not compute the number of elements in this array; element type is 'const int', not 'VALUE' (aka 'unsigned long') [-Wsizeof-array-div]
                             sizeof(ec->machine.regs) / sizeof(VALUE));
                                    ~~~~~~~~~~~~~~~~  ^
vm.c:2489:34: note: place parentheses around the 'sizeof(VALUE)' expression to silence this warning
compiling dmyenc.c
1 warning and 1 error generated.
make: *** [vm.o] Error 1
make: *** Waiting for unfinished jobs....
~ $

Trying to figure out the problem by looking at the message, it didn’t seem like something I could fix. Searching the rbenv Github issues didn’t give many clues. Knowing that rbenv uses ruby-build to automate the Ruby build process, I looked at the issues reported. It looks like I was not the only one having similar problems.

CleanShot 2021 04 24 at 21 51

I tried several of the suggestions found from those issues and none of the solutions worked.

Solution

I decided to turn to my friends on Twitter to see if anyone had faced this issue. Twitter never lets me down and Robby Russell of Planet Argon came through,  suggesting installing Ruby with these CFLAGS:

CFLAGS="-Wno-error=implicit-function-declaration" rbenv install 2.6.7

It worked perfectly and I was able to get additional versions of Ruby installed. This should also work if you’re having problems with asdf Ruby version manager too. Asdf uses ruby-build behind the scenes.

I wondered why I hadn’t stumbled on this solution in the ruby-build issues on Github. It turned out I saw the issue but ignored it because it referenced installing older versions of Ruby when Xcode 12 was installed. I have Xcode 12 but was installing new versions of Ruby. The ticket was a little deceiving as it worked with new versions as well.

For those interested in the details, they can be found in the ticket – Installing older Ruby versions on OSX after Xcode 12.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Mac, Ruby Tagged With: rbnev, Ruby

Fixing Out of Diskspace Errors on Amazon EC2

April 20, 2021 by Rob Bazinet Leave a Comment

Tweet

Recently, I was working on a side project and deployed an update on my favorite deployment platform, Hatchbox.

The deployment ran and failed with an error message:

error An unexpected error occurred: "ENOSPC: no space left on device

Hatchbox gives users a nice interface to deploy Ruby on Rails applications. Everything is taken care of for us, from server provisioning to application deployment. It’s really a nice service and allows lots of customizability.

This particular application is provisioned on Amazon EC2. Hatchbox provisions to multiple providers including Amazon and DigitalOcean but their responsibility for the platform does not go beyond provision. Issues such as what to do about these types of errors is up to the user.

Finding the Problem

I am running an a t2.micro instance which does not have a lot of space but I didn’t expect to run out so soon. I ssh’d into the server and ran a check of disk space with the

df -h

command. The result showed me what was wrong:

CleanShot 2021 04 16 at 16 22

Granted, this shows I have 93% free and that should be enough to deploy my application and it is. I removed some old deploys and freed up enough space to finish the deploy. Disk space was at 99% before cleanup. This was a temporary solution and adding space is needed.

Fixing the Problem

If you are familiar with how managing partitions on a Mac or Windows system then you should have an understanding how to solve this problem. On these system there is the idea of a partition, which has a set size. The partition is formatted for a given file system and can then be used to store applications and data. These partitions can have their size adjusted and formatted for use. This is how this problem is solved.

This application is running on Amazon EC2 and those servers use Elastic Block Storage (EBS) for server storage. The nice feature of EBS is the ability to easily change the size of the drive allocated for our use. The default size for our t2.micro instance is set to 8G, which seems small but can be easily expanded.

Loggin into the  Amazon Web Services dashboard, the available volumes are shown. Selecting Volumes listed under Elastic Block Store on the left side column reveals them:

CleanShot 2021 04 16 at 16 25

I have a single volume listed, you mileage may vary. Choose the one for the EC2 instance needing more space. Notice the display shows 16g of storage. This screenshot was taken after the changes were made to expand the volume.

Right clicking on the volume shows a nice menu:

CleanShot 2021 04 16 at 16 26

Finding this menu was not obvious when first arriving at this page. You will want to choose the Modify Volume option from the popup menu where you will see the following modal:

CleanShot 2021 04 16 at 16 27

I changed this option from 8GB to 16GB for my purposes. Once you click the Modify button it will take some time for the change to take effect. The status will be here:

CleanShot 2 2021 04 16 at 16 25:

The State field will change and update with progress. Mine took about 5-10 minutes. When it’s all done it will return to showing In-Use.

Unfortunately, once this process is done the disk space is not expanded. You have to expand the volume on your own.

Expanding the Volume

Amazon does have a nice document to accomplish this task. It’s a good idea to take a look at this and follow their specific directions including taking a snapshot of the volume in the event there are problems.

I decided against the snapshot because I didn’t have any production data I needed to be concerned about.

These are the steps to finish expanding the volume. I assume you are familiar enough with the command line to complete these steps. These steps need to be completed from the EC2 instance itself. Access to the instance is accomplished with secure shell (ssh). Root privileges are also needed.

1. Check the file system in the volume. Mine shows ext4.

CleanShot 2021 04 16 at 16 23

The Type column shows the format of the filesystem. Take note of this, it will be needed later.

2. Run lsblk to look for the partition that needs to be extended.

CleanShot 2021 04 16 at 17 18

This shows my partition after the upgrade had been done. The disk size showed 16G and the partition (xvda1) showed 8G.

3.  Extend the partition

We need to extend the partition so we can use it in the next step. From a terminal window of your EC2 instance.

sudo growpart /dev/xvda1 1

The 1 at the end indicates the partition to be expanded.

4. Extend the File System

Since the filesystem of the drive I am targeting is ext4, I use the command:

sudo resize2fs /dev/root

Once this command completes running another df -h shows our partition is expanded and we no longer receive errors when trying to deploy to Hatchbox. This issue is not unique to Hatchbox and will solve this problem for any method used to deploy to your Amazon EC2 instance.

Conclusion

This process is not difficult but does require paying attention to some details. If you aren’t familiar with how-to access remote systems or how partitions and filesystems work then you might want to find a friend who can help.

I hope this helps… 

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Infrastructure Tagged With: Amazon EC2, Amazone EBS, Hatchbox

Discover DevUtils.app – Toolbox for Developers

April 19, 2021 by Rob Bazinet Leave a Comment

Tweet

I love finding great tools that solve problems I face everyday. I came across the DevUtils.app recently which is a toolbox with lots of tools to make our day better.

CleanShot 2021 04 18 at 20 58

I’ve made use of several of these and it works great. 

The list of tools is pretty broad and I can imagine the author adding more to the toolbox as time goes on.

The toolbox is not free, $25 for use on two Macs. Seems like a bargain. I found the source code is available too but I hope is if you find value, you support the author. As developers we know how much time it takes to create and support a nice piece of software.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Utilities Tagged With: DevUtils

Overcoming the Mimemagic Fiasco

March 26, 2021 by Rob Bazinet Leave a Comment

Tweet

I’m sure if you are a Ruby on Rails developer, you have heard about the fiasco that is Mimemagic.

It seems a component used in the Mimemagic gem was under a GPL license which was different than Mimemagic but because of how these licenses work, trickles down to users of Mimemagic. In this case the Ruby on Rails gem. If you’re interested in some of the background, the Ruby on Rails issue, Dependency on mimemagic 0.3.x no longer valid #41750, can fill you in.

The gem was yanked from Rubygems and because of this, the gem could no longer be installed so builds broke everywhere. Users received the message:

Your bundle is locked to mimemagic (0.3.5), but that version could not be found
in any of the sources listed in your Gemfile. If you haven’t changed sources,
that means the author of mimemagic (0.3.5) has removed it. You’ll need to update
your bundle to a version other than mimemagic (0.3.5) that hasn’t been removed
in order to install.

I have several clients needing a way to resolve this problem.

I came up with a couple different options.

Option 1 – Remove Dependency

After a bit of research I discovered that Mimemgic was used by the Marcel gem which is required by ActiveStorage. If the application did not use ActiveStorage then removing the dependency would solve the problem. If you use ActiveStorage, this is not an option.

Implementing this is pretty straightforward. Opening up your config/application.rb, you should see where Rails is required:

require "rails/all"

Instead of requiring all, just require what you need and remove the ActiveStorage dependency. This is what requiring rails/all includes:

active_record/railtie
active_storage/engine
action_controller/railtie
action_view/railtie
action_mailer/railtie
active_job/railtie
action_cable/engine
action_mailbox/engine
action_text/engine
rails/test_unit/railtie
sprockets/railtie

Just remove the second line and require each of these individually and you will be all set.

Option 2 – Change how the gem is included

Since the Mimemagic gem is open source and the code is in a git repo, we can identify the commit created when version 0.3.5 of the gem was released. Some commits that should solve the problem:

  • 0.3.3  https://github.com/mimemagicrb/mimemagic/commit/d5ebc0cd846dcc68142622c76ad71d021768b7c2
  • 0.3.4  https://github.com/mimemagicrb/mimemagic/commit/64b60d125432bde900fa4d9f77fb6f057a0c325a
  • 0.3.5  https://github.com/mimemagicrb/mimemagic/commit/01f92d86d15d85cfd0f20dabd025dcbd36a8a60f

My projects have been using v0.3.5, I found the commit and added this to my Gemfile:

gem 'mimemagic', '0.3.5', git: 'https://github.com/mimemagicrb/mimemagic', ref: '01f92d8'

This is a short-term fix. I expect once the Rails team resolves the dependency, new versions of Rails will be released.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: Ruby on Rails, rubygem

Redis::CommandError – MISCONF Redis is configured to save RDB snapshots

March 22, 2021 by Rob Bazinet Leave a Comment

Tweet

I recently ran into a problem I hadn’t encountered before on my Mac. I was getting an error from Redis:

MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.

The fix is simple. From a terminal window, enter the Redis CLI. From a terminal window type:

redis-cli

Use the command:

config set stop-writes-on-bgsave-error no

You should get an OK response, then type exit to get out of the reds-cli.

Try again where you received the error and everything should be working as expected.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Tips Tagged With: redis, Ruby on Rails

frozen_string_literal: the not so magical comment

March 16, 2021 by Rob Bazinet Leave a Comment

Tweet

I have been working on a project over the past year for a client with a large Ruby on Rails application. The project has allowed me to learn more about how large Rails applications are developed and managed in the real-world. I’ve picked up some real gems to help scale Rails applications which I’ve used in some of the smaller applications I maintain.

One of the gems I learned about was the use of this magic comment:

# frozen_string_literal: true

This comment was added to every Ruby file in this company’s application, which included several microservices along with a large main application. The files numbered over 1,000.

I read up on the use of this magic comment use in other projects and the results seen. One in particular was Sidekiq from Mike Perham. Mike documented his use of the magic comment and how it improved his use and helped cleanup his code.

Ruby 2.3 introduced a very nice option: each Ruby file can opt into Strings as immutable, meaning all Strings within that file will automatically freeze, with a simple magic comment at the top of the file.

Mike includes some benchmarks that show improved memory footprint for Sidekiq. This was enough for me.

I had one relatively small application that had an API component I was optimizing (Rails 5.2.x and Ruby 2.6.6). I thought about the use of the magic comment and decided to give it a try. I added it to every Ruby file in the project and was included as part of the weekly deploy.

The deploy was done after hours one evening and I was ready to witness the magic.

Unfortunately, this magic did not happen. I noticed right away the response times of API calls were slower, not faster. Maybe I was seeing the effects of cold cache calls and things would improve overnight.

The next morning in fired up Skylight to check the response times from the API. To my surprise, the response times did not improve. Since the only change in this deploy was the use of magic comments, I decided to rollback the changes. This application runs on Heroku, rolling back with really easy and does not require reverting the code back and redeploying.

The result was noticed instantly:

IMG 1186

Response times drastically improved as you can see from the above graph.

At this point, I don’t have any reason to believe it’s not the magic comment that caused these longer response times.

During my brief research about the comment’s use, thinking there was more to using it than simply using it everywhere, I ran across a thread from the Ruby lang issue list. The threads title, Reconsider impact of frozen_string_literal on dynamic strings, I found interesting. Maybe this is a clue and dynamic strings being frozen in my application is part of the problem.

It sounds like there is a benefit to use this feature but not everywhere, the exact result I saw in performance graphs.

I am still exploring when to use the magic comment and when it shouldn’t be used. If you are using this throughout your applications it might be worth measuring with and without their use. Any others have more information to share, please reach out.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: Ruby, Ruby on Rails

Status Bar in iTerm2

April 7, 2020 by Rob Bazinet Leave a Comment

Tweet

I’m a big fan of iTerm2. I’ve used it since it’s inception and haven’t looked back. Even after all of this time I still discover features I didn’t know existed, mainly because I wasn’t looking for them.

I recently discovered you can have a status bar at the top of the terminal window with various stats and data points. My status bar is simple at the moment; containing system CPU usage, memory usage and disk throughput.

2020 04 07 09 38 21

How did you do that?

Adding the status bar is pretty simple. Go to iTerm2 -> Profiles -> Session:

2020 04 07 09 33 49

Check the box for Status bar enabled and then configure the status bar by clicking the Configure Status Bar button.

There are a bunch of options here so I think it’s worth playing around with how the terminal looks. There is even an option to run a script, which opens up many possibilities. Simply drag-and-drop the component you want to have in your status bar. Select a component you made active and you can customize it by the Configure Component button.

2020 04 07 09 33 21

If anyone sets this up and adds calls to scripts, I’d love to hear how you use this feature or how you get creative with other features.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Mac Tagged With: iterm2

Supporting Multiple SSH Keys on macOS

April 3, 2020 by Rob Bazinet Leave a Comment

Tweet

If you’re a developer, on devops or a system admin you probably use an SSH key to log into remote servers.

I am typically on multiple projects at one time and some organizations require I generate a unique SSH key in order to work with them. I’ve been fortunate until recently that my personal SSH key was acceptable.

So, how can you have two or more SSH keys available on your system at any one time? I am running a Mac but I assume this would work on Linux as well.

It’s not hard and when setup, it works really well.

Getting Started

The first part is generate a new SSH key. Understand that the email you’re using here may be an email provided by you client or company. It may not be the email you normally use.

ssh-keygen -t rsa -b 4096 -C "[email protected]"

There are a few different types of keys you can generate. If you’re interested, GitHub has some good help with SSH keys.

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/rbazinet/.ssh/id_rsa): example_com_id_rsa

I use something specific to the company for who I’m adding the key. You can see here the new SSH key is example_com_id_rsa. Please be careful here, if you leave the default you may overwrite your existing key. You probably don’t want to do that.

The Key is the Config

Head on over to where your SSH keys are stored, probably in ~/.ssh directory. Edit the config file, simple called config. It probably looks like mine:

Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa

Add your additional host. I added mine above the original.

Host git.example.com
Preferredauthentications publickey
IdentityFile ~/.ssh/example_com_id_rsa
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa

The host is the system you need access to. It could be a git server or some other resource. Wildcards work here so if you need to access all resources on s particular domain, you would handle that here. There are a lot of things you can do in the config file and way you do them varies in complexity. If you want a more detailed explanation, Digital Ocean has a good resource.

I hope this helps.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Mac Tagged With: macOS, ssh keys

Using the Microsoft Ergonomic Keyboard on macOS

April 1, 2020 by Rob Bazinet Leave a Comment

Tweet

IMG 6167

I’ve been through a fair number of keyboards over the years, some expensive and some not. One of my favorites is still the CODE Keyboard, which I wrote about before. I still love this keyboard but I was starting to have pain in my forearms after a long day of typing. I keep coming back to the Microsoft Ergonomic Keyboard to on macOS. Why? Because it’s a tradeoff between being ergonomic and being inexpensive. I’ve seen some other customizable keyboards in the range of $350 but I haven’t found the large price tag necessary.

One annoyance when using many keyboards is the fact that they are setup for Windows operation system and not macOS. This means the Command key is not to the left of the space bar as Mac people expect. The Microsoft Ergonomic keyboard has the Alt key in that location. It’s a simple fix.

Go to System Preferences -> Keyboard -> Modifier Keys…

2020 03 31 10 47 16

Notice the Option Key and Command Key defaults. The Mac is recognizing the Alt key as the Option key. We need to make a change.

MicrosoftKeyboard Before

The easy fix is to swap the two keys in the modifier. Option becomes Command and Command switches to Option. Click OK and everything should work as expected.

MicrosoftKeyboard After

This saved the day with properly mapping the command key. If you need other keys mapped differently on this keyboard, there is another option. Karabiner is a powerful utility for the Mac that allows a wide variety of keyboard mapping. It was more than I needed.

I hope this helps.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Mac Tagged With: Ergonomic Keyboard, macOS, Microsoft

Next Page »

Recent Posts

  • How to Fix Rails Flash Rendering When Using Hotwire
  • Hotwire Fix for CORS Error when using Omniauth
  • Fix Installation of Ruby using rbenv on macOS Big Sur
  • RailsConf 2021 and the Future of Conferences
  • Fixing Out of Diskspace Errors on Amazon EC2

Categories

Services I Love

HatchBox - Easy Rails Deploys Fathom Analytics
Follow @rbazinet

Rob Bazinet (ruby.social/@rbazinet)
@rbazinet

  • Working to wrap up my current consulting gig by mid-April. I will be looking for the next thing soon. If anyone has… https://t.co/sg3cSV9yqM
    about 12 hours ago
  • I’ve been spending some time using Notion AI lately and it surprisingly good. Since all the rage lately is ChatGPT,… https://t.co/cUXFWIRCVV
    about 3 days ago
  • I think these steps are true for any target audience. https://t.co/0ht6rIzOW3
    about 3 days ago
  • I’ve been enjoying a show from the Magnolia network called The Craftsman. It’s mainly about woodworking but his phi… https://t.co/sWTUBbSsl6
    about 4 days ago
  • I found the resource I was looking for last night that is similar to https://t.co/Pyn0IIjRdP, it is… https://t.co/U7TMe77FMF
    about 4 days ago
  • RSS - Posts
  • RSS - Comments
Find me on Mastodon