DEV Community: Joshua Schenk

The Rust Programming Language by Ben Goldberg

Joshua Schenk — Wed, 03 Apr 2019 04:56:05 +0000

I recently went to a talk on Rust the other week that was hosted by RIT's own Linux User Group or Ritlug. The talk was given by Ben Goldberg, a fellow GCCIS student at RIT, and was an intro to programming in Rust and its possible uses.

The Content

Ben's presentation was split into two parts, a slide deck portion as well as some coding examples. Ben describes Rust as a language that provides both performance and control, and raved about the languages safety and compiler features. He went over syntax, typing, scope, and other topics as an introduction into the language and what it's like to use it. A particularly interesting part of Rust is that variables are immutable by default; the mut keyword is used to make a variable mutable.

The Talk

I really liked the talk and its structure. The atmosphere in the room felt pretty informal for a presentation, audience members would shout out questions to Ben or provide more context to some of his talking points. The dynamic nature of the presentation was really interesting and I hope that a lot of the presentations given at Ritlug are this interactive. Everyone one in the room seemed to be working together to paint a more detailed picture on the language, and it's a lot different when compared to other talks I've sat through.

The talk was great and informative, and I want to learn a lot more about Rust when I get some time to sit down and read through the Rust Book and documentation which were both recommended highly by Ben for those that want to jump in.

Bugfix update

Joshua Schenk — Thu, 21 Feb 2019 03:14:28 +0000

Hypothesis

Hypothesis is an open source library that allows you to write tests using "property-based testing", and is still a work in progress. It aims to be an easy alternative to QuickCheck without making users have a knowledge of functional programming. I happened upon the repository looking to fulfill my requirements for my bugfix assignment and found a bug that looked easy for me to start working on.

The Bug

The bug I decided to work on is more of a clarity issue. I'm going to be making sure that a variable is of the correct type and make a test to see if the error check is properly working, I have a good idea of what I have to do, I just need to make an appropriate test and figure out what format would be best when raising errors after checking.

HFOSS Literature Review 2

Joshua Schenk — Wed, 13 Feb 2019 03:06:30 +0000

Roads and Bridges

I recently read the first half of Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure by Nadia Eghbal as an assignment for my FOSS course, and I really enjoyed it. I plan on finishing the other half of the paper when I find time next week, but for now I have to focus on my schoolwork. Eghbal is a software developer and an advocate and researcher for open source software.

Her paper is all about the influence of open source software and the world's reliance on the tools made by unpaid programmers making a project as a passion or by necessity. It's a great read on the prevalence of FOSS, as well as the benefits and shortcomings that come along the way. I really enjoyed the articles discussion of the lack of organization and contributors as well as the small figures describing different open source tools with short bios of how they were developed and by who. While it is very verbose, I really think that this article was worth the read.

Eghbal posses some really interesting questions about the future of open source software, that she doesn't provide a clear answer to in the sections that I've read thus far. How do we plan on incentivizing more people to contribute and maintain code to help fix the offset between contributors and users? She points out that the large number of people now using open source tools greatly outweighs those contributing to it, leaving the owners of the project with too much work to do. She also asks whether its ethical or logical for open source projects to take large amounts of money from ventures without plans for return on investment, describing a lot of these projects as 'loss leaders'. She paints a bleak picture for projects like OpenSSL and other projects that are soon to run out of funding or have maintainers retire.

npm

I was also required to read an issue thread on npm 5.7.0 as well. The post is very clear on what issues the user had and what they did to cause the issue. npm 5.7.0 was causing file permission changes and the user was simply reporting the issue and telling the team how to reproduce it, but the comment thread was a huge dumpster fire. Apparently people trying to update the the npm package were getting a pre-release that clearly wasn't working. The thread quickly turns into a huge argument over whether or not it was the user's fault for negligence, or the maintainter's fault for not clearly labeling that it was a pre-release (running npm install would install 5.7.0). People began discussing a topic that Edgal discussed in her paper: that there are only two people maintaining this critical tool used by countless numbers of people. The thread got so bad that the maintainers had to restrict access to the thread. The new repo for npm doesn't even have an issues section to post on, while the old one is sitting at a cool 2000+ issues right now. No wonder they seemed overwhelmed.

Playing with Fyre

Joshua Schenk — Wed, 06 Feb 2019 06:34:11 +0000

Fyre (not the festival)

I haven't done too much this week other than coursework so here's a short post about Fyre - a small computational art application I found while browsing pamac. It allows you to explore different chaotic versions of the Peter de Jong map equations. It has a ton of different settings and numbers to play with. It even has an animation window so you can make gifs or short videos of the shapes moving around. I've played around with it a bit over the past couple of weeks and I found that they make fun profile pictures. Here are just a few of the pictures I've made using the application.

Messing with Manjaro

Joshua Schenk — Wed, 30 Jan 2019 03:36:17 +0000

My Background

While I have had quite a bit of experience messing around in the CLI of Ubuntu, both on my schools machines and on my WSL (Windows Subsystem for Linux), I haven't taken much time to pick my own flavor of Linux and use it as my daily driver, but after being recommended Manjaro by a friend of mine, I decided to give it a try.

What Is Manjaro?

Manjaro is a Linux distribution based off of Arch, but with a few key differences. Manjaro focuses heavily on usability and it's "work straight out of the box" mentality, while Arch focuses on simplicity and, relies on its users making things work for themselves. Arch has fast releases, making it cutting edge, but very unstable. While Manjaro maintains a very stable OS while maintaining a rolling release schedule.

Why Manjaro?

Since Manjaro focuses on stability, it has a much slower release schedule when compared to Arch. It's a trade-off, but users will be able to have a much more reliable Operating System. Manjaro also uses pacman, Arch's powerful package manager. In doing this, Manjaro is compatible with the Arch User Repositories. If you're willing to wait a little longer for features, you'll have a very nice OS. But if you'd rather be up to date with Arch's packages, you can switch to their 'bleeding edge' release schedule. Manjaro is also a very user friendly for a lot of people getting into Linux since it has pamac (and Octopi if you're using the KDE version), Manjaro's GUI alternative for downloading new packages.

Downloading Manjaro

The first thing you need to do when downloading Manjaro is picking out a desktop, there are a ton of different options from xfce to cinnamon and mate, I suggest doing your own research if you want to know more about them, but I'd suggest xcfe or KDE. I went for the KDE version for its flexibility and since hardware restrictions weren't an issue with my laptop. Downloading Manjaro is very easy if you're using the right tools. You can test it out on a virtual machine or live-booting from a usb, if you like it then you can install it from the live-boot. As for making the usb bootable, I'd suggest using Image Writer as opposed to Rufus, since I was having trouble with grub versions. I linked a guide from the Manjaro site if you need more info.

Conquering Manjaro

One of my friends told me that you need to conquer your OS before it becomes a powerful tool for you to use. I liked that term a lot, and I definitely had to go through a couple of loops to get Manjaro working the way I wanted it too. It's not perfect yet, but I'm in a good usable spot right now. Here are a couple of things that I had to go through that you might also have to deal with when you start up Manajaro.

Installing Packages

The first thing I did to get machine up and running was installing all of the packages, to install something with pacman you need to type pacman -S into the Konsole. If you aren't that comfortable with the terminal yet, or just want to browse the packages, I'd recommend installing pamac with, pacman -S pamac and opening it up from your start menu.

Beeping Noises

I'm looking through pamac for different packages and I accidentally press backspace on the search bar and extra time BEEP. I instantly thought that could be annoying, my computer was muted and yet the beep was still loud and clear of course. So I look up how to fix it and stumble across this page. It's a little unclear, so here's what I did.

I opened up my Konsole and typed in this line rmmod pcspkr which the site claimed would disable the BIOS speaker. I went back to pamac to test it out and the sound was gone. I figured out the issue but I would have to do it every time I booted up my computer. So I needed a way to make it disable on startup. The easiest way I found to do this was with Blacklisting, which you can read about here.
To do this:

Go into your modprobe.d directory with cd /etc/modprobe.d/
Using your favorite text editor (and the sudo command), add a .conf file with the line blacklist pcspkr in it.

Problem solved! (This doesn't disable normal audio)

Disabling My Touchscreen

Another thing that wasn't so clear was disabling my broken touchscreen, that would have random presses without doing anything. This was a hardware problem that I knew was going on for a while. ~~After a lot of research I downloaded a package called xorg-xinput and was able to solve the problem. Here are some steps.~~
~~1. Open up Konsole and download xinput using pacman -S xorg-xinput~~
~~2. run xinput and look for the name of the device you want to disable~~
~~3. run xinput disable 'ELAN touchscreen' but use the name of your device instead~~

~~And that's it!~~

Edit:
This will not work when you restart your computer, the solution I used to this problem was one I derived from this thread. Here's what I did:

Move to the xorg conf directory with cd /usr/share/X11/xorg.conf.d
Use ls to look at your .conf files just to make sure
Open the 10-evdev.conf file with your favorite text editor for vim: sudo vim 10-evdev.conf.
Look for the "evdev touchscreen catchall" section and add Option "Ignore" "on" to the section.

It should look like this

After I saved the file and rebooted my computer the touch screen was disabled!
Hope this helps!

I've enjoyed messing around with Manjaro and if you're looking into trying out Linux or switch from another distro, Manjaro would be a good place to start!

HFOSS litreview1

Joshua Schenk — Wed, 30 Jan 2019 01:28:14 +0000

How to Report Bugs Effectively by Simon Tatham is an article I read recently about how to effectively report bugs when working on a collaborative project. Tahtham is the free-software programmer that created PuTTY, a commonly used free SSH client. In the article Tatham gives a very thorough explanation of how to report bugs to programmer. While I have had a lot of experience debugging my and other people's code, I haven't thought about how to properly articulate these problems to my peers. I think that this article can help people who are having trouble with communicating their issues to others, and people who want to be more efficient at debugging their own code.

In one section of the article titled "So then I tried...", Tatham presents a concept many people don't practice when encountering a problem in their code, restraint. Tatham claims that when encountering a bug many people immediately start trying to fix it without thinking everything through. This can cause a simple problem to become much worse. He advocates for proper planning and research before doing something irreversible. While I do think that the ice isn't always as thin as Tatham suggests in his article, I agree that stopping to think about what happened and planning out a solution before rushing in to fix it would help me a lot in my problem solving process.

While the previous section I mentioned felt more about debugging my own code, the rest of the article is very focused on reporting bugs to other people's projects. The article was was a verbose, but it was a nice description of the proper ways to report bugs as a user or collaborator. Tatham discusses how to provide concise, helpful information to people that need to fix a bug or help you figure out why something isn't working for you. He wants people to provide thorough steps on how to recreate a problem, and be very specific in what you see when things start to break.

First Flight

Joshua Schenk — Wed, 23 Jan 2019 02:50:02 +0000

IRC

Making an IRC chat was pretty easy, although I had to change my nickname halfway through due to it already being registered. I'm trying to get riot working with freenode but it keeps telling me that I'm not invited to the group.

Email

The email list was really easy to get registered to.

Blog

I originally wanted to use jekyll on github pages, using atom for rss feeds but I ran out of time doing work for other classes so I'll use dev.to for now.

Forges

I already had a github and bitbucket so that was all fine- the yaml file was really easy to make and took no time at all.