DEV Community: Eisea904

Public Domain vs Open Source and copyright resources

Eisea904 — Thu, 15 Oct 2020 19:50:17 +0000

Public Domain

*How is it different from Open Source?

Types of Open Source Licenses

*Is your program copyrightable?

Citation and Resources

1.
While the designations 'Public Domain' and 'Open Source' can both imply a communal goal they are distinct and well intentioned, careful programmers should make themselves aware of the difference. Public Domain is a designation assigned and maintained by governments and can vary widely across
borders.

For instance, IMSLP the International Music Score Library Project hosts an api that allows primarily classical music researchers and performers to access a massive database of musical scores (sheet music). The server however is based in Canada where copyright ends sooner after the creator's death than in America. If this api were used in an American for profit program, there could be penalties incurred if rights are infringed upon. Another example comes from game systems. After all one of the most common applications of software is with gaming. 5e.Tools and TheTrove are resources for tabletop gaming that must be hosted in other countries due to differences in what qualifies as Public Domain. There is currently an explosion of applications designed for these games and systems and yet programmers must be careful not to use pirated sources that conflict with either their own morals or the laws of their governments. On the internet piracy is everywhere, and the term 'piracy' often covers more shades of gray than just bootlegging movies. In our work we may make programs for a wide variety of fields in which we ourselves are not professionals. This is only one way in which we must always be aware of and investigating the implications of our work.

As well, Open Source is not necessarily Public Domain.

Open Source is a label and license actively included by the author; Public Domain is a category of intellectual resources designated by governments
Furthermore, a program or document are not inherently Open Source merely by the author's decision not to include licensing, rather in the USA the lack of clarity will force it to be considered under a type of implicit copyright, one that as collaborators take and build upon your project, may soon disclude you the original creator. Some sharing sites include a form of open source documentation in their mandatory User Agreements, Github is just one of these.

2.
There are many different open source licenses . Some confer more or less freedom to use, build upon, and distribute programs built upon the original code. In general, programmatic systems cannot be copyrighted, but the literal written code and documentation and the expression thereof can. And if your code builds on someone else's earlier code, then you may be able to copyright your additions, but this would not include any original components of the base code.

3.
Referencing Code
https://runestone.academy/runestone/books/published/StudentCSP/CSPCreativity/referencing.html

Do you know if your code is open source?
https://www.publicknowledge.org/blog/do-you-know-if-your-code-is-open-source/

Types of Open Source Licenses
https://choosealicense.com/licenses/#unlicense

Public Domain Is Not Open Source
https://opensource.org/node/878#:~:text=%E2%80%9COpen%20Source%E2%80%9D%20describes%20a%20subset,with%20the%20Open%20Source%20Definition.&text=%E2%80%9CPublic%20Domain%E2%80%9D%20means%20software%20(,is%20not%20restricted%20by%20copyright.

Common Mistakes when Beginning Rails

Eisea904 — Mon, 05 Oct 2020 14:37:49 +0000

Several steps can go wrong when setting up a new rails api. This article will hopefully help debug issues that may arise.

Often when learning any new coding material, example variables like 'project name' are written with with brackets on either side. This is a reminder not to include those brackets. File and repository names can also be easier to reference without typos if they do not contain spaces. The example code below to create a new rails project would be written in the following way:
$ rails new <project name> --api --database=postgresql
$ rails new project_name_api --api --database=postgresql
By including 'api' in the project name we know that this repo only contains our back end and is separate from the frontend.

Next we will talk about creating our migrations and models. There are several pieces of information that go into creating a new model, the Name, attributes, associations, and more; these three will be discussed here with examples. Our example will be a Teacher model that has_many assignments and a joiner model Assignment that belongs to both a Teacher and Student.
'g' is short for 'generate', either can be used here; I will be using 'g'.
Teacher --< Assignment >-- Student

$ rails g model Teacher name:string

the model name 'Teacher' is always capitalized
if attribute type (name is a string) is not given, then the attribute type will default to a string. Thus the above code could be written as: $ rails g model Teacher name
A Teacher has_many Assignments, however this is not the place to include has_many. Do NOT include something like 'assignments:has_many' in this console command. has_many associations only go in the 'app/models' folder.

$ rails g model Assignment name:string teacher_id:integer student_id:integer
OR
$ rails g model Assignment name:string teacher:belongs_to student:belongs_to

For our Assignment model either of these will work. The associations can be written either as teacher_id:integer or with the teacher:belongs_to macro which will generate a foreign_key as an integer. The functionality is the same, but the result will look different in the migration folder. If both are included in the console command, the error ArgumentError: you can't define an already defined column 'user_id' will appear when you run db:create and you will not be able to make a 'db/schema' folder or seed any data.

After this, you will put the associations belongs_to :teacher and belongs_to :student in the 'app/models' Assignment file.

Rails Landmarks - Don't Get Lost!

Eisea904 — Tue, 15 Sep 2020 04:51:20 +0000

Opening a repository that uses Ruby on Rails can be an intimidating experience to those new to the experience. There are many folder with many folders with many files. However just like moving to a new city, once familiarized with major landmarks you can begin to enjoy your drive to work and find new things to love in this new big city!

Let's take a look at the file tree to see what fun things there are in this town.

There's a lot here, even before expanding most of these folders. We're going to look at two groups - landmark folders in app_folder/app and landmark files outside the /app folder. We'll go over the primary function of each item. A simplified filed tree is below:

app_folder/
--> app/assets/stylesheets/
--> app/controllers/
--> app/models/
--> app/views/
app_folder/
--> config/routes.rb
--> db/
--> --> migrate/
--> --> schema.rb
--> --> seeds.rb

The app folder houses our MVC, Model View Controller folders. These are three of the most beautiful parks in the city, and powerful tools that rails gives us. Our model folder houses associations: our belongs_tos has_manys, and validateses. With this, our program can understand that a comment belongs_to :post and that a user can have_many :posts.

Controller holds the methods that each model can use. Most models (a site's users, Facebook's posts) can be created, read, updated, and destroyed (CRUD), among other capabilities like sign in. The view folder holds the .html files, literally what your audience views on the browser. There should be a folder for each model, each with a .html.erb file for every action or page you give that model. assets/stylesheets contains .css files, one for each model.

As you cruise through your new town you're likely to see many road signs, some with directions and arrows, others with advertisements of what is nearby. Our config/routes.rb files is where to find most or all of the arrows and paths that a user on your site with be sent down. This is where we find our verbs: get, post, patch, delete, etc. A simple tool for knowing how to write these paths is RESTular.com . Your migrate folder houses all your migrations and the schema.rb folder shows all of the elements that go into your models.

If you have children you will no doubt want to help them feel safe at home in this new town. The seeds.rb file is the backseat of your minivan, with plenty of room for all your rambunctious example material and class instances.
There is a lot to see in this new home of yours. Relax and enjoy the ride!

A Common Error and a Debugging Tool, end & pry

Eisea904 — Tue, 01 Sep 2020 17:02:30 +0000

When starting Ruby, there are common errors you will undoubtedly encounter. Here we will look at the most common of these and a powerful debugging tool, pry.

Example 1

One of the most common errors will look like this:

blog_examples.rb:10: syntax error, unexpected end-of-input, expecting end'

Let’s dissect this…

file_name:line_that_returns_error: error_type, details

This error is telling us that our file is missing an end. The part that may confuse beginners is that it is line 10 that gives us the error. This may be misinterpreted as "line 10 needs an end." Actually, it is telling us that by the end of the file (line 10) it was expecting at least one more end than is present. And now we know that one of our methods is missing an end. Looking through, we can see that #gossip(name) needs this fix.

Example 2

The sister error to this is
blog_examples.rb:8: syntax error, unexpected end', expecting end-of-input

There is now an extra end that we forgot to delete when we deleted #say_goodbye!

Pry is an invaluable tool in debugging, but it can also be confusing so let's talk about how to use it and what it can and can't do. Firstly, unless you know it's included elsewhere in your environment, add require 'pry' to the first line of any file you want to use it in. Go to the line or end of the section you want to test, hit enter/return to make a blank line and there put binding.pry .

When this program is run, it will pause at that line and be able to access everything within its scope that came prior. The binding.pry will not be hit if that piece of code is not run. If you are using it within a method, then at the end of your code you need to call that method to run it. In the example above we call on #say_goodbye at the end with say_goodbye(John) . If we put a binding.pry inside of the #say_goodbye method, it will only now be hit. Pry can also only access information within its scope, so within a pry session, we cannot access variables defined within other methods, for example.

Once pry is working, you will see in your computer's terminal the word pry and a colon. Here you can type ideas for the following lines. It's a sandbox, so instead of deleting your code to try an idea and then saving it only to delete that and try your next idea (and so on...) we can simply type ideas in the pry session. When we are done, type exit to go up one layer toward your normal terminal (and usually pry sessions are only one layer deep). exit! will always take you completely out of a pry session.

In example 3 our binding.pry can be used to check what is being passed as the variable name_as_string. When you type name_as_string into the pry session in your terminal, it should give us "John". However, anything inside the prior method #say_hello is outside the scope of #say_goodbye , so we cannot access those things while pry is on its current line.

Example 3

A note on pry, it will not "tell you" what is wrong with your code. It will however save you time and give you your error messages much more quickly than if you had to change your code within the file and save with each attempt or idea.