Open-Source software has become a vital source of tools for the development community, as well as innovative software. Recently I have become interested in finding out just how many of the applications I use are open-source, while at the same time finding new open-source software. I want to expand the software I have at my selection. First, let us reestablish what open-source software means: software that can be modified, enhanced, or inspected by developers who are not the original creators. This is done by packaging the source code along with the software so that it can be edited by anyone who knows how to.  

To start off this extensive list, Mozilla Firefox is open source to my surprise. Firefox has its source code internally available within the browser itself and can be found by using the URL https://searchfox.org/mozilla-central/source and has guidelines for contributors up on a separate website. Mozilla also has the source code for countless other projects up on GitHub, such as Gecko, the rendering engine for Firefox. Continuing down the list we got GIMP and Blender, two powerful tools for any aspiring artist out there. In recent days I actually downloaded Blender onto some of the computers at the school I work at. While I am not going introduce 3D modeling to my middle schoolers, there have been students who have shown an interest in the subject. I thought having Blender available to these students would foster interest and motivate these students to pursue more. It is for situations like these that I believe in the importance of open-source software and the need to have these tools available to all. GIMP has helped me out here and there in the past, and since it is the only image manipulation software that is free, I am also planning to implement it in my classroom. 

One of the most important pieces of open-source software is none other than the operating system Linux. So many pieces of technology are running on Linux, or some variation thereof. Android OS is based on Linux and is also open source, Chromebook OS is based off Linux, several routers are using Linux. From cars, TVs, to even super computers, Linux has been a reliable operating system for a massive amount of hardware. Even NASA has completely switched over to Linux as of 2013. I am partially convinced to convert to Linux after all the compelling evidence I found.  

Finally, I have already mentioned LibreOffice in a previous blogpost as well, but it bears mentioning here. Microsoft Office is such a ubiquitous piece of software it is almost impossible to work in any sector of society that does not make use of it. The downside is that it is expensive for many. This is where LibreOffice comes in and offers a free alternative that does not require making an account of some kind like Google’s services. It perfectly embodies the spirit of open-source software.

Open-Source software has become a vital source of tools for the development community, as well as innovative software. Recently I have become interested in finding out just how many of the applications I use are open-source, while at the same time finding new open-source software. I want to expand the software I have at my selection. First, let us reestablish what open-source software means: software that can be modified, enhanced, or inspected by developers who are not the original creators. This is done by packaging the source code along with the software so that it can be edited by anyone who knows how to.  

To start off this extensive list, Mozilla Firefox is open source to my surprise. Firefox has its source code internally available within the browser itself and can be found by using the URL https://searchfox.org/mozilla-central/source and has guidelines for contributors up on a separate website. Mozilla also has the source code for countless other projects up on GitHub, such as Gecko, the rendering engine for Firefox. Continuing down the list we got GIMP and Blender, two powerful tools for any aspiring artist out there. In recent days I actually downloaded Blender onto some of the computers at the school I work at. While I am not going introduce 3D modeling to my middle schoolers, there have been students who have shown an interest in the subject. I thought having Blender available to these students would foster interest and motivate these students to pursue more. It is for situations like these that I believe in the importance of open-source software and the need to have these tools available to all. GIMP has helped me out here and there in the past, and since it is the only image manipulation software that is free, I am also planning to implement it in my classroom. 

One of the most important pieces of open-source software is none other than the operating system Linux. So many pieces of technology are running on Linux, or some variation thereof. Android OS is based on Linux and is also open source, Chromebook OS is based off Linux, several routers are using Linux. From cars, TVs, to even super computers, Linux has been a reliable operating system for a massive amount of hardware. Even NASA has completely switched over to Linux as of 2013. I am partially convinced to convert to Linux after all the compelling evidence I found.  

Finally, I have already mentioned LibreOffice in a previous blogpost as well, but it bears mentioning here. Microsoft Office is such a ubiquitous piece of software it is almost impossible to work in any sector of society that does not make use of it. The downside is that it is expensive for many. This is where LibreOffice comes in and offers a free alternative that does not require making an account of some kind like Google’s services. It perfectly embodies the spirit of open-source software.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. ‘Keep It Simple Stupid’ and ‘Don’t Repeat Yourself’ are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like ‘first_name’ or ‘ customer_id’, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.