My final presentation is coming quickly, this is a great time to look back on what I did and what I learned. This week I did very little coding, and focused my time on creating a presentation that will accurately describe how I felt during the last few months.
Looking back to when I started this project gives me a funny feeling. I learned so much, not only about coding and planning, but also about how I approach problems and think about them. It is hard to call that person who started this project “me a few months ago.”
One of the big things that I lost sight of, that I had to convince my audience of, was the importance of what I was doing. When I started, I understood the importance of laser cutting and its potential to teach and allow people to be creative. I knew that anything to make this process easier would help everyone involved. From the time I started coding, I forgot about this. I was coding to edit and .svg file, I wasn’t coding to help people. Writing my presentation forced me to remember why I did this and the importance of it.
I learned a lot about software development and the process that goes into it. The collaboration is a huge part, and a very helpful one too. I learned much more than that, I learned the importance of planning, and the process of problem solving. BASIS has always told me the importance of planning, I followed along, but mostly for the grade. The SRP showed me the importance of planning. The times when I did do planning, I flew through the section with little hiccups. The times I failed to plan, I went slowly and got stuck. The value of planning is what I walked away. I am forever thankful for that.
If you are curious, here is my program, uploaded to GitHub:
For the past few months I had be using the same .svg file, and changing my code. This poses a problem: “Does my code work on all files, or just this file?” I tested my code on a couple different files, and I got an answer: “It works… sometimes”. This week was dedicated to fixing bugs that did not show themselves on my original file.
My GUI made it very easy to change parameters and the file I was editing; however, it was not very quick. Every time I edited the code, I would have to close the program, run it again, select a file, enter in the values, hit run, then open the .svg file and check if my edit was successful. This was time consuming, so I copied the program and removed the GUI to expedite the process.
One of the problems I encountered when changing files was the connecting of two endpoints. I think I had done some math wrong, or something. When I ran the program, multiple lines would connect seemingly random endpoints in strange ways. I ended up rewriting the code for endpoints with my previous code as a guideline. This worked great. Another problem I encountered was dealing with piecewise paths, or paths that are not straight lines. The problem here was there were many different points on the line and it was difficult to connect the lines to the correct set of points. It would take a lot of time and energy to fix. I made the decision to put this off until I am more free.
I fixed some other little things in the code, and it works for .svg files with mostly straight lines. I will eventually try to make it even more general, but that is a large task to undertake. At this point, my code can be called “completed,” there are many other things I can do to make it more polished, but it serves its purpose well.
This week was dedicated to creating a Graphic User Interface (GUI). So far this program was run by only me in my command line, this was great for me, because it meant I could find errors easily and I didn’t have to invest any time in making it look nice. The program was coming to a close, so it came time to create the user interface.
I know very little about creating interfaces. In Mr. Balanda’s AP Computer Science, where I learned to code, we skimmed over the interface section in favor of more interesting topics. I did some research and I came across tkinter. tkinter is the most popular python library for creating dialogues (the program window). I did not want to learn tkinter, so I piggybacked off of what others have done. I found some great tutorials on tkinter and how to use it. I took what they wrote and put it into my code. Of course it did not work right away. I did some heavy tweaking to make it work for my purposes. I learned enough about tkinter to understand how it works and how to make it do what I want. That is all I needed in this situation.
In everything, but coding especially, it is not necessary to reinvent the wheel. Using what others had done and adapting it to your use is the name of the game. Collaboration is a big part of coding, and stackoverflow.com is the place to do it. Odds are someone else has tried something similar to what you are doing. Stackoverflow is a place to post solutions to problems for the world to use, it is the Yahoo! Answers for all things computer science. I credited a lot of what I used in my program, to give proper recognition.
This week was a little lackluster. I did not have a large problem that needed solving, instead I had a handful of little things to fix or add to my program. I spent a good amount of time thinking: “What does this program need? What can I add to it?” This on of my least favorite things to do in coding. Having a well defined purpose is really what makes coding fun.
I found a way to edit the stroke widths of all the lines and shapes in the file. The next logical step was to make a method to edit any attribute of the file. I took what I had done for changing the stroke width and generalized it to take any attribute and change the value to anything. This was pretty simple and really useful for the editing of the file.
I also needed a way to delete paths in the file. The way I accomplished this was not as optimal as I would have hoped. I found the endpoints of the line I wanted to delete. I then searched the file for a line that had the same endpoints. And then I deleted that section from the text of the file. I think I was caught up in my “plaintext solution,” so I did not think much about better ways to do this. I think I can use the element tree function of the library I was using and deleted the line that way. This would have been much more elegant.
I found that I often started coding without proper research or planning. This is something that will try to remedy in the future. Planning is there to reduce time and confusion. I often forgot this.
I was taking a walk a couple nights ago and BAM. It hit me. I new exactly how to edit stroke width. I ran home like a madman, muttering nonsense. A couple of years ago, when I had to write an essay I had procrastinated, I found that sleep can be replaced with exercise and cold showers. I coded for 2 hours, then ran 2 miles, then coded more, ran more, a quick shower, then back to coding. I was up all night, around 4am I went to bed and slept happy.
The solution I found was incredibly simple. It pains me to think about all the time I spent in frustration. Luckily brains are pretty good as suppressing uncomfortable memories, so I hardly remember last week.
.svg files can be read as a string (text), and I can edit strings easily. If I just search the string for the sections that include “stroke-width:”, then I can change the stroke width with ease. I called this the ‘plaintext solution,’ because I was reading the file as the computer reads it, with no special formatting beforehand. This solution worked perfectly for me. Last week was not a waste, as I may have made it seem. I learned what I could and couldn’t do to .svg files, I also saw a lot of different ways to edit files. A lot of what I saw I deemed unimportant when I saw it, however, I couldn’t have come up with the solution with all that information.
I am pretty happy with the solution I came up with. I am sure there are other solutions that work just as well, but the point of problem solving is to find a solution that works.
This week could be described as an ego check. I spent most of the week in frustration. My code has changed little since last week, but I now know a handful of ways to not edit the stroke width.
The python library I am using reads the .svg file as an element tree. This means I can look at a specific path (line) or rectangle. Then, read the attributes of the element, such as stroke width or color. This is pretty easy to do, however there is a disconnect between the elements I am accessing and the actual .svg text. This means that it is very difficult to edit parts of the file using this methodology. I spent a couple days at Starbucks trying to figure out how to make this route work. I eventually stopped, took a step back, and decided to figure out a different way to go about this problem.
The next idea I had was to look for a different library that would be more willing to edit specific attributes. I scoured the internet and looked far and wide. I found a couple libraries that could edit attributes of the .svg file, however they all lacked some other important functionalities. So I decided that this was not the best route.
This week was really frustrating yet humbling. I spent a lot of time attempting to fix a pretty simple problem. I really didn’t get that far, I do now know a lot a ways that do not work, which is somewhat helpful. At this point I began to realize that with more planning and research I could have skipped a lot of this frustration. I will find a solution next week…I hope.
This week was more productive than I anticipated. The project was moving smoothly until a couple days ago when I hit a roadblock.
I have successfully connected lines that end near each other. I did this by retrieving the endpoints of all lines, checking location and stroke color. If the points are close enough and the colors match, a line will be drawn from one end to the other end. Adding this line was difficult, as I had to edit the original file and make sure the new line meshes correctly. A similar process will be required to add additional lines for various cases.
The task of adding lines went smoothly; however, I recently hit a hiccup. I am working on editing the stroke width of lines, which is easier said than done. I have spent many hours switching between Google and my code with little luck. My first idea was to edit a specific index of the string that describes the line, but as I quickly discovered, strings in Python are immutable. I found a couple ways to address this issue, none of which work correctly. I am still thinking about how to fix the issue of editing values of the file.
Next week will be devoted solving this problem, I will determine the next route of action after this issue has been resolved.
This week was devoted to putting ideas into text. However, there were a few hiccups along the way. The various libraries I had found on the internet lacked some functionality, so I found new ones that fit my task better. Currently I am using svgutils and lxml. I will probably need some other libraries, but as far as I can tell, this is as much as I will need.
The coding has gone fairly smoothly so far. I have been able to read from the .svg file, which I thought would be a much more difficult task. I did this by using functionality from etree, which is included in lxml. I have been able to convert the appropriate information about paths from the .svg file into numbers and other variables. I have also created an .svg file from a Python script.
I am currently having some trouble editing the .svg file. I have encountered so technical problems regarding Python lists. I have also not attempted to edit the existing .svg file; I am unsure if I will edit the file or create a new file with edited values. Next week will be devoted to addressing these issues.
The joy of having the computer do what I want has been a large motivating factor. I am glad I have started coding, and I am excited for the rest of the project.
Over the past few days, I have begun the planning stage for the coding. Just like most things, an outline will help me keep focused on specific areas. This outline started as a collection of tasks that need to be done to solve the problem, such as connecting the ends of lines that are close, deleting lines that are too close, and removing mistake lines. The outline then became more complex, and specific. I then broke these tasks down further, describing how I will tackle them. For example, I will find an end point of a line, then I will check the surrounding area for a diffrent line, if there is one, I will connect the two with a straight line. In some of these cases, I jotted down some code.
I have recently discovered that the svgwrite library does not support the editing of .svg files, only the creation of new files. I have found a library that should allow me to edit .svg files with precision. It is called svgutils, created by Bartosz Telenczuk.
The next week I will began coding and putting my ideas down. I will continue to outline tasks on paper before I attempt coding.
So far, I have really enjoyed this project. The experience of finding I did something wrong, or was not using the correct thing felt very real. I expect, in this project and in the future to get things wrong and this was a great example of that, I did not get discouraged, in fact, it was exciting to be wrong.
This first week has been dedicated to learning how to edit .svg files, a task harder than I anticipated. I am approaching this problem in the same way I have solved problems in the past. I planned out how I am going to solve the problem, and worked my way down to the most basic level.
I found that it is possible to directly edit .svg files from a Python script. This process required multiple libraries and other programs I needed to install and import. In doing this, I have learned a lot about using my computer from the terminal. I found a library that allows me to edit .svg files from Python with ease, it is called svgwrite. This is seeming to be the most promising route.
I have also researched a different technique, which is more specific to my case. Inkscape is the open source vector art editor that Xerocraft uses. This program allows for extension scripts to be written that can also edit the .svg file. This would go though Inkscape as opposed to the stand-alone program previously mentioned. This solution seems less general, but can give me experience with open source software.
In doing this, I have realized I have lost some of my coding skill. When I hit walls and frustrations, I take a step away from what I am doing to relearn and practice Python.
Next week, I intend to learn how svgwrite works, and possibly how to create extensions for Inkscape. I will plan my route of attack on the problem before I start coding.