#Don't try and open a design from Excel in Google Sheets

[mariana-oconnor]

How do you design your patterns for knitting?? They are so pretty! 😍

In Excel (or the spreadsheet program of your choice*). First I set the ratio of the cells so each cell is one stitch. Double knitting, like for the blanket is a 2:3 ratio, roughly, which means that every two stitches across is about the same length as three stitches upwards. So I set the width of each column to 0.3 cm and the height of each cell to 0.2 cm. (For contrast, standard colourwork is usually closer to a 4:5 ratio, so don't use double knitting diagrams for single knitting or vice versa)

(Weirdly, in Excel you only seem to be able to adjust in centimetres if you put the spreadsheet in print view first, so it looks like different pages, idk why. Excel sucks like that I guess.)

*Not Google Sheets, because last time I checked it doesn't allow background images. This may have changed since.

Then I put a thick black border around the limits of my pattern. For the baby blankets it's about 176 columns by 264 rows, though the width is subject to change a little based on the pattern (if I decide on a repeating border it has to be divisible by the right number), and if I change that, I might adjust the length as well because I want the blankets to be roughly square.

Once that's done, I decide on a theme and a rough idea of what I want it to look like. For my most recent blanket I knew I wanted mountains because my friends like to hike. I knew I wanted space because one of them is really into space stuff. And I knew I wanted chickens because the other has chickens that she loves.

When I know roughly what elements I want to include, I do an image search for silhouettes of that thing. This is one of the reasons I haven't made any of the patterns available, because copyright. I do transform the images I find, and some of the elements (borders, patterns) are entirely from my own mind, but there's a lot that's based off images I find. I don't specifically go searching for creative commons images because it's personal use and the only place I even show pictures of them is here on Tumblr. Like I said, I transform them, and it's personal use, so I'm pretty sure I'm clear just making my blankets for my friends, but any further might be questionable. Idk. Copyright is a thorny sort of a thing.

ANYWAY. I get a silhouette image (silhouettes because they're clearer, although one of the chickens on the latest blanket is from a photograph, but that's trickier to work with). Then I set it as the background of my Excel spreadsheet.

One interesting thing about Excel is that the zooming in and out doesn't affect the background image like it does the cells, so I zoom in or out until the image is about the size I want in relation to the size of the whole blanket. Then I colour in the cells on top of it. At first it's just the cells that are completely filled in in the image below, then it's the ones that are half filled in or more.

Once that's done, I remove the background image and I fuck around with what's left (essentially a pixel art version of the silhouette). This is the stage that takes a lot of time, because there's often a lot of tweaking to do to make it look good. Fine lines and curves are difficult, and sometimes things just need to be changed. For instance, the owl on my most recent blanket started out life as a long-eared owl and I changed it into a barn owl because that suited my aesthetic more. The mouse I adjusted the size of multiple times and the shape of the back and the ears and the nose... and the tail... to make it fit the space I wanted it in and also to make it look more mouse-like. Literally changing one cell can make a huge difference to how something looks, it's crazy.

For borders and decorative bits, I tend to just mess around with colouring in the cells in swirly patterns until I come up with a shape I like. Repeating patterns are a lot easier to do, but do require you to do maths to make sure they fit properly. This probably requires patience, but I find it strangely addictive and zen-like.

For the ivy on my last one, I used silhouettes for the leaves, then used the transform tools in excel to mirror the five or six different leaf silhouettes I had vertically and horizontally, then moved them around and connected them with twisting lines to create the impression of vines.

Once I've got all the separate pieces, I copy them all into the outline I have of the blanket and move them around (it's important to keep the originals separate, because when you move things in excel you can often copy over something and chop off an ear or a tail or half a bird).

But yeah, then I move stuff around until the layout works for me. Sometimes at this point I have to resize things, which is annoying.

Then, when I've got things roughly in place, I mess around with them some more until they look right. It's a lot of trial and error at this stage

For example, in the dragon and unicorn blanket I did, the dragon's tail was messed around with a lot at this point. I had it curling one way, then the other way. I made it really long. I made it really short. I had it end with spikes. I had it end with the spade.

As a final touch, I then add the more random details that don't need as much work, like the stars or the snowflakes, which are fairly easy to just design on the spot. I move those around as well, until I'm happy with them.

Then I start knitting.

The design does often evolve as I'm knitting. For instance, after seeing how the tension worked on the mouse in my most recent blanket, I realised that the planet was going to be stretched thin the way I had initially designed it, so I tweaked it to be fatter so it would appear more round in the finished product. Similarly I added some more leaves to the tree and moved the top branch down a bit for better framing.

That got kind of long, but I hope it helps.

[the-nox-syndicate]

SysNotes devlog 1.5 (backend edition)

Hi all! In this post I will continue the development of my plurality management web-app SysNotes. Today I will be focusing mostly on setting up the databases for the app, as currently test data is stored in the code itself. This severely limits the interactivity and features of the web-app, so it is time to separate it.

In this devlog, I will explain the basics of databases and how the Laravel framework interacts with them to give you an idea of what goes on on my screen and in my brain while I code. This will just be an overview of some technical behind the scenes, nothing will have changed on the front end of the app.

If you missed the first devlog, you can find it here.

What is a database?

A database at the most basic level is a type of file format that has tables. You can think of it as a "spreadsheet file" like the ones you can open in Excel or Google Sheets. The main structural difference between a database and a spreadsheet is that in a database the tables can have relationships. For example, the relationship between a users table and a posts table is that one user can make many posts, and a post can only belong to one user. This is a one-to-many relationship. You can ask the database to give you all the posts related to a specific user. In my app, each user account will have multiple alter profiles, for example. When a user logs in, the app will only fetch the alter profiles that this user created, and show the profiles to them. You can do a whole bunch of other things with databases, that's why I like them! The main functional difference between a database and a spreadsheet is that a spreadsheet is used for data analysis and manipulation, like a fancy calculator, while a database is used to store data. Each table stores data related to one type of object/person/place. Like how spreadsheets can be opened in Excel, database tables can be opened in database software such as MySQL Workbench or HeidiSQL, which is what I'm using since it came with Laragon.

(What my Heidi DB looks like at the end of the devlog)

Plan for today

The users table already exists in my app as a result of installing the Laravel Breeze starter kit, so I don't have to worry about designing this table. With that out of the way, I can think about adding feature-related tables. The first feature I'm adding to my app is the ability to create alter profiles and to fill in the sections on the profile page. The first step is therefore to create an "alter profiles" table and to normalize it (more on that in a bit).

Setting up the database tables (and why it's a pain)

Migration files

When using the Laravel framework, you're not supposed to create a new table or edit an existing table through the database itself - it has to all be done through code. This is done using a file called a database migration. The migration specifies the table name, what columns it should have, what data types the columns should be, and what other tables this table may be related to. This is done so that if you give the code to another person and they download and ran it, their database will be set up the exact same way is yours. Therefore, the migration file makes your database changes portable, which is especially useful when copying code from your personal computer onto the server where the web-app is running. You don't want to set up your local database and then find out that it doesn't work the same way as the one that runs the actual app! Migrations aren't just for creating a new table. You also need to make a migration file for every structural change you want to make for that table, such as adding a new column or changing a column's name. Updating a table's structure after it's already been set up and filled with data has a chance of corrupting the data. Therefore, I always impose this expectation of myself of always getting the database structure right on the first try (i.e. in just one migration).

(My migration file for the alter profiles table at the end of this devlog)

Normalization

Normalization is the act of splitting up a table into 2 or more tables in order to simplify the data structure, reduce duplication, and make database queries more efficient. To illustrate, let's consider the alter profiles table. An alter can have several traits, such as "energetic" or "nervous" and so on. Let's say we should store it in a "traits" column like so:

Now let's say we decide that the word "sad" isn't quite the right descriptor, and we want to change it to "melancholic". To do that, we would need to edit every instance of this word in the table. In this example, it would only be in 2 places: on Benji's profile and on Colin's profile. But what if there were many melancholic alters? That sounds like a lot of work! What if you misspell it on accident somewhere? You won't be able to filter alters by trait properly! Instead what would be better to do is to split (haha) the alter profile table into that and a traits table. Now we will have:

So if you wanted to change the word "sad" to "melancholic", you could do it in just one place, which makes it easier and more maintainable. This is just one small example of what normalization can be. There are actually like 7 levels of it, and even I don't remember them all. In fact, what I will be doing in my app is a step further than the example and use something called a "pivot table" - a whole new type of headache! The point is, figuring out the architecture of database tables is a whole science in on itself 😩

Actually doing the coding

After brainstorming how to normalize it, the alter profile will need to be separated into several tables: alter profiles, alter characteristic types (traits, likes, dislikes, an triggers), alter characteristic values, and alter statuses (such as active, dormant, and unknown). Each profile can then reference the characteristics and statuses tables. This way, alters can like or dislike the same thing, creating the ultimate modularity!

The (pretty technical) steps are as follows:

Create the (model with) migrations for the individual tables and specify their table structure

Create a pivot table and set foreign IDs to point to the individual tables

Define the relationships in the model files

It took me a few tries to get past migration errors, and I accidentally rolled back my migrations too many times, losing my users table 🤦‍♂️ As i don't yet have any alter data in the database, I just re-registered my account and nothing was lost. Heart attack simulator lol.

Seeding data

As I'm just working with test data, I don't really care exactly what words and images are used where as long as it works. I also don't want to pain-stakingly input test data into every field for every profile every time I have to delete (drop) and remake (migrate) a table. That's where seeding comes in. Seeding is an automated process that generates dummy data and inserts it into the database, ready for me to test. I'll admit I've never done seeding before - at work I've always worked with a copy of an existing database that has been filled by years of use. But it's never too late to learn! I used seeding to create dummy data for alter profiles and trait values (trait types and statuses has to be manually inputted because they have pre-defined values). I couldn't quite figure out how to seed pivot tables, as they define relationships rather than data. So I had to add those manually too. I still have a ways to go until I'm a real developer lol.

(My Alter Profile factory at the end of the devlog - i left pronouns blank because I wanted them to somewhat match the names, so I added them manually afterwards)

(My Alter Profile seeder at the end of the devlog)

And here are my seeded tables! The faker is limited to using Latin words so I couldn't get the characteristics to look realistic. But it will be fine for test data.

(I have changed the alter names to match the names from the previous devlog)

...All this just for the profile page! But when designing a database's architecture, it is important to anticipate ways in which the database will grow and facilitate new relationships from the start. This was a tiring coding session but it has paved the way for the new and more exciting features!

What next?

This devlog was just for setting up the database tables - in the next devlog we'll get to actually use them in the app! The plan is:

Pull data from the database into the profile pages to display the freshly generated dummy data

Add a way to create new profiles using the New Profile form

Edit the profile information