Forem: Akintunde

Made Our Supabase Alternative Open Source

Akintunde — Wed, 27 Dec 2023 07:32:44 +0000

Finally made Nobox Open source.

This is just an Introduction Video to get feedback.

https://www.youtube.com/watch?v=qhk0biCL97w

Running Open Source Models locally with a TAURI GUI

Akintunde — Tue, 07 Nov 2023 18:07:23 +0000

I've always been a fan of the Ollama Project.

Recently, I created a simple web UI for it. It was just a slap-together of react codes.

I've also developed a desktop application with improved features and user-friendliness. However, I can't share the MacBook executables just yet because I need to sign the app (which I plan to do soon).

My main goal is to share the open-source code with anyone who's interested in experiencing the beauty of running open-source models locally, without requiring any specialized programming skills. I also welcome contributions from the community.

You can find the project on GitHub here: https://github.com/Akintunde102/ollama-chat-desktop-app.

My Rough Ollama Local WebUI

Akintunde — Sat, 05 Aug 2023 02:39:13 +0000

Install from here: https://github.com/Akintunde102/ollama-webui

Introducing Nobox.cloud: A Backend as a Service for JS Devs

Akintunde — Wed, 02 Aug 2023 21:51:27 +0000

Late last year - 2022, I suddenly found myself in a situation where I got flooded with several solutions I needed to build with little or no resources to bring them to reality, time being the scarcest of these resources.

Best thing I could do, as I thought then, was to build a backend as a service product that would at least remove the backend challenge off my list. I guess , you would be wondering why I didn't just use firebase at the time. I just didn't like to do that, the integration process was already disappointing. I wanted something that fit into my workflow and most importantly, a BAAS that gives me a custom-experience most backend-as-a-service out there couldn't give.

I ended up building nobox.cloud with help from some of my friends and since then, it has evolved far beyond being just a personal tool – it's now being embraced and used by others too!.

Bottom line here is: We would really love it if you could check out nobox.cloud and give us some feedback.

Currently, we're in the Alpha Release stage and have decided not to have a waitlist, so registration is open for a limited time.

During this Alpha phase, we're particularly eager to gather feedback from users like you.

I'm looking forward to hearing your thoughts on nobox.cloud!

Dynamic Offline Storage In React Native Applications

Akintunde — Tue, 30 Jun 2020 01:13:22 +0000

A while ago, I built a react native App that allowed people to view and save African Fashion Styles. The app simply displays about 400+ african fashion styles and then allow you save the styles you like.

This post isn't really about the app, it's about certain storage complexitiies I had to deal with in the process. Complexities that became simple afterwards.

I will not go deep into the discovery and analysis of the complexities and how I unfruitfully tried solving those problems with the use of RealmDb , Sqlite and AsyncStorage. I will go straight to the eventual simplification of these complexities.

I will like to mention that there are actually a lot of other similar Fashion Gallery Apps already.

So you might ask,

Then why did you build yet another one?.

Well, here is my response

I wanted to create one that had what the users of such apps really wanted: offline Storage , which subsequently helps to limit Data Expenses that occur when you have to always download the images each time you open the app.

Here is the Breakdown

I created A Node Server, that housed these images and the code that aids their retrieval. This server will feed the app with these images when the app gets installed and initialzed as it is somewhat wrong, unconventional and "rude" to add 400 images (about 146 mb) to an APK . More so, it will be very much unnecessary to launch a new version of app simply becuase I need to add new images. This helps make the app lighter to download and makes image updates easier without releasing new version.
When the user downloads the app and launches it, it connects to the nodejs server , to download an Object file ( imageDict )that shows the details of this images including their names and path details on same server.
Then it downloads this object file to the device filesystem, this file is about 1kb, so it feels light and appropriate to do that.
After that is done, a function called fetchAndSave() runs through this object file and uses the details present to download these images to the user's device using rn-fetch-blob to fetch the files from the remote server , then subsequently using rn-fetch-blob again to save each image as a local file. Note: Before each image is called, it checks if image already exist locally to avoid unnecessary overwriting.

Here is a twist, before fetchAndSave() is called, the app actually starts and the gallery opens. This seems inappropriate becuase you might wonder , if you have not saved , what are you going to display in the gallery but its actually the best feature of the app, in my opinion.

Let me explain.

Each Picture Container has a dynamic URI that can either be local or remote. If the image is available offline, the uri becomes an base64 encoded version of the offline image, otherwise the uri is a remote url that fetches the image from the remote server, while the loader gif keeps the viewer in wait.

Why

So that for the life time of using the app, you only have to wait for the each image to load remotely once, every susbequent view of an image will be local and let's not forget fetchAndSave is already loading meaning at least 60% of the images would have been offline before you get to them even if you internet is only modest in speed. I tested that.

More so, if you abruptly turn off your internet , and close the app, fetchAndSave() will not download an image twice when it runs again on a consequent app launch. So, it is very easy to tell the user the exact amount of data he or she will have to expend during the lifetime of the app usage. For now, it is 146mb, which is roughly, the exact size of all the images and object file which acts as the manifest.

All though, I try to keep the user a bit on a prepatory image loading screen before the gallery opens , this is to avoid bad user experience when the user's internet is pretty bad or turned off , in which case, the user is made aware to Please turn the internet on.

A SimpleExplorer Built With ElectronJs, ReactJs,and Typescript

Akintunde — Sun, 13 Oct 2019 12:39:19 +0000

Image: Quantized.com

I promise to say the truth and nothing but the truth.

Here it comes.... the truth...Drum rolls.

I have been busy

Yeah, that is the truth , I said it. I am free.

It doesn't look like something I should be scared to say but then, I believe I should not be too busy to finish a project I started.

Anyways, it happened. I started a project and left it unfinished.

This is not an article about the love and hate relationship most developers have with electron apps. It is more about a Simple File Explorer App I created with Electronjs. I have been on it for a while and I hope someone might just tell me what he or she thinks about it.

Here are some details about it:

Github REPO: Simple Explorer

It is an ElectronJs App
It is meant to be a File Explorer for PCs/Macs
It has a bundle of features like file preview for some media content types
It can read Code files and preview it with good indenting, all thanks to some wonderful react libraries.
The architecture of the app was cannibalized from the Museeks App, meaning I downloaded Museeks Source Code, removed the core codebase while leaving the file structure and configuration behind, then I added my own codes to make SimpleExplorer.

Why did I Cannibalize Museeks?

Museeks as a project was too attractive. It was architectured for Typescript & React usage. What else can be more wonderful?

What do I need from you?

Tell me what you think
Adopt this project as yours
Contribute to it
Be a friend.

Thanks for taking your time to read. Expecting your response.

Development Tips for Software Peeps

Akintunde — Mon, 01 Jul 2019 06:59:37 +0000

This is will be my very first post on Dev.to.

While it's really nice to be here, I believe it will be nicer if I could just add some value by pouring my hearts out about certain tips I think can help boost developer productivity.

I will be emphasizing on time management and staying in ones comfort zone long enough to leap out of it.

Here they come!

Beware of commuting, it steals time.

Some of us already know this. For those that I have not observed, take note. It will be nice to just invest in a fast transportation system, live close to work or above all, work remote or half-remote than waste endless hours on the road when you could be working on something. That way, we might just be able to save some extra hours for self development each week.
Commuting Steals Strength , focus and then time and productivity

While commuting could help stretch the bones, loosen some body bolts and improve cardio efficiency, there are times when it just messes things up with the stress and eventual fatigue that can come from being stuck in traffic. I try to reduce commuting as much as I can , most especially when I am in a busy city. I expect every developer to think of a way to deal with this.
Don't Overthink A Project

There is a reason why some people chose to "Just do it" rather than over-plan a project or an idea until "they the idea fades out of possible execution". This is what happens when we over-think things through it. If you want to be really productive as a developer (or as anything else), it is just better to type away on a side project rather than just over-plan it before you put your hands to the keyboard. When you discover that the planning process is taking too long, I suggest you "just do it". While it is good to make a piece of software as performant as possible. I believe it is better to have an imperfect project than have none because an imperfect project can be improved. While this is a good tip, I only apply it to my side projects. Production Codes are a different ball game entirely.
Stay in your comfort zone long enough to leap out of it

Just because your project is better coded in another language does not make it impossible in your present skill set, at least not all the time. If this is the case for you, would it not be nice to at least have a portfolio with projects than have none or one with scanty projects because you want to build the most performant code ever. If you have the time to learn something new, fine!, go ahead but if you don't , I suggest you use your present skills , learn later when the time is there and then come back to improve whatever you have done.

Thanks for reading it all. I hope someone found these tips useful.