Blog posts by Carmen Cordis
19 Sep 2014 »
MozTrap can show you a list of tests you can run in your own Firefox browser. When you specify your build and browser version, you can mark each specific test as passing or failing. If the instructions are unclear, you can even write in comments to ask for clarity. MozTrap is a great starting point to get an idea of what a test looks like. The site helped us understand how a “bug” is a specific browser activity that’s not working correctly.
Mozmill helped us set up our own automated testing! We mostly chose to work in Git for this. We each had interesting discussions about how to write the most accurate code lines in our terminals to get the automated testing to work.
- Bugzilla (also called BMO) is the main venue where Mozillians talk to each other about possible bugs, confirmed bugs, bugs that have been assigned to specific people as their personal projects, and bugs that have been fixed.
- There’s also a helpful page about making contributions to Mozilla where you can review various ways to help out!
Contributors to the main repo will get the files on their own machines and make changes that improve the collection of files.
Contributors will then need to finalize their changes through the Git process. This includes adding individual changes to the “stage” of changes, kind of like an audition. Then, when you’re absolutely sure the changes are playing the role you want them to, you can commit those changes to be final. Afterwards, contributors should update their own version of the main repo by “pushing” the committed changes to GitHub. Doing so will update their repo version.
The next step is to submit a “Pull Request” via the GitHub site. A pull request is saying, “Project leaders, will you please pull my new files over to your main file collection and include my changes in the main file collection?” The project leaders will then merge the new files with the older ones.
- As a Learner, I relate to the world by learning as much as I can. I’m not perfect by any means, and we all have differing phases of memory, but I love exploring new ideas and learning new things. I also learn by teaching, when I can.
- In terms of Context, I seek to understand why things are the way they are, based on historical events that may have caused them to be the way they are. The StrengthsFinder accurately identified that I love researching ancient history!
- Individualization isn’t what it sounds like. I didn’t like the name at first, but I agree with the Strength as one of my top 5. I strive to empower people as individuals, with unique lives, lenses, and experiences. In order to work well with multiple people, I make it a priority to validate their individuality.
- Connectedness seems related to Context. I see events as connected to each other, and I seek out the “webs” connecting things. My learning style involves linking concepts together to create new things.
- The Relator strength involves deconstructing information, to make it understandable for multiple types of people. I love this one, because I’ve been very inspired in my life to support people through tutoring and teaching. I really enjoy presenting information, creating concept maps, finding different ways to explore ideas, and brainstorming through creative methods!
Week Two of the Ascend Project has been intense, thrilling, frustrating, and uplifting at times. I’ve definitely learned this week that computers will “only do what you tell them to”! We’ve learned a lot of new programs and commands for our terminals in such a short time. The learning process is slow and steady, but we’re getting there.
I’m still not caught up on all the Mozilla profiles and social media profiles I’ve created for the project!
It’s been a while since I’ve engaged so much in social media, and the “tech community” (if it can even be described with only one term) is so vast that I barely know where to begin.
As part of my goals for Ascend, I need to make an ongoing list of each of my profiles, in order to keep current with updates, and in order to track my ongoing contributions. The more I learn, the more I can contribute.
I need to refine the little website I built last week with Webmaker. It’s colorful, but simple, and perhaps it could use more spacing between the text. I would also like to link the Ascend Project’s pages!
This week, we focused our energies on running tests, checking on bugs, and helping to reproduce bugs found by other contributors. We had a lot of fun calling each other on our computer screens by using the video call features in Aurora! It was rather humorous to talk to someone sitting across the table, and hear them echoing from my computer.
Running the calls in Aurora helped us to identify some bugs, and to explore what it’s like to test individual features of a program. We wanted to make sure they’re running the way they were intended to run, and the way we would like them to run.
Here are some Mozilla resources we used to help us identify, report, and reproduce bugs:
It took several tries for me to finally understand how the file-path worked, and I wondered if I was the only person who really didn’t understand. When it finally became clear how to make the code line work, I felt so relieved. I’m thankful for the Ascenders who stuck with me to help me understand. Then, I got to help another person understand, too!
Some Ascenders are making tutorials in how to run Mozmill tests. Check them out! We were able to make our Nightly browsers open a bunch of tabs, download test files, and dance all around, without even having to touch the keyboard! All of these tests were designed to catch bugs.
Here’s a lovely link to show the results of my automated Mozmill tests in the Nightly browser:
Often times, people will report a bug that’s actually a duplicate of another report. When I filed my first few bugs, some of these were marked as duplicates. I felt a little disheartened by the duplication, but, at the same time, I realized that multiple reports about the same bug will bring attention to the need for the bug to be fixed.
Bugzilla has resources for sorting bugs, searching for bugs to help with, and contributing patches to fix the code.
The Whiteboard tag [good first bug] means that someone reviewing the bug believes that a new contributor could fix it, with enough research, context, and time.
Different bugs are in different programming languages, so people with varying experience levels can all help.
We also searched for bugs with the designation “steps wanted”, which means that a team of people are working to reproduce the bug, so that it can be fixed through trial and error.
18 Sep 2014 »
Our Week Two goals for Ascend include writing an instructive guide to help new contributors on their journey through Open Source learning.
Because Open Source is open, there’s so much to learn, and there are so many resources to help people learn. During Ascend, we’ve all been choosing topics to turn into teaching moments. These tutorials will be readily available for anyone who is starting fresh or who wants a refresher.
As part of my own learning process, I am going to learn how to embed images into a blog post using Markdown format. Screenshots are great for visual learners.
I pondered for quite some time about possible topics for my tutorial, and it’s become clear to me that modern technology allows teams of people to work on the same projects and contribute to each other’s work.
My tutorial will focus on how one person can use the Git interface to contribute their own independent work to an entire team’s main project. It will be at the basic level, because I am still learning things, but I hope it helps.
The first step to using Git to contribute to your team is to understand some vocabulary!
What is Git? Here’s a picture directly from the source, git-scm.com :
Programmers (and people who use computers) make changes to files all the time. When people work together, they’re all making changes to files, and then those files will be combined into the team’s project. Git is a system designed to help people be more aware of how each team member changes the files.
“Version control” means tracking the changes made to a file or set of files over time.
It’s important for programmers to be able to keep track of which version of a program they’re using, what the features or files looked like in older versions, and making sure the proper changes are added to newer versions.
We call this “version control” because the Git system helps to ensure accuracy when making changes to files, and we can also reverse any unwanted changes by using the right techniques in Git.
People who use Git to track changes to files can store their team projects and their own independent work on a resource website called GitHub.
Here’s a picture from GitHub:
GitHub has been such a useful tool for our work in Ascend!
A repository is a collection of files which has been made available on the GitHub site. One person or team creates the repository of files, and other people around the world can read these files, import them onto their own computers, and suggest changes for the original author or team to review and approve.
A repository will sometimes be called a repo, for short. We’ve certainly used this term a lot!
GitHub works in the following way:
Version control is really useful because we can actually reverse the process of deleting files if we deleted them by accident!
I spoke with K about how she accidentally lost some picture files from her local computer, and it was frustrating to try to figure how to get them back. It turns out that her GitHub repo still had the files saved, and she got them back by retrieving them from GitHub! Yay!
I wanted to help myself and others remember the basic format for making changes with Git and GitHub. It’s very basic, and there are many resources to help online but here’s a Git Song I wrote, set to the tune of the popular “12 Days of Christmas” song.
It’s in reverse order, but it kind of follows the song, and Step 8 is like “Five Golden Rings”.
The Twelve Steps of Git
When we learned to use GitHub, our teachers said to me: Make a pull request to send files up the tree!
When we learned to use GitHub, our teachers said to me:
1) Fork your own Repo,
“Forking” means copying a repository of files to your personal GitHub account.
2) git checkout your branches,
This is a command I typed into my Terminal, which you can find on a Mac by typing Command-Space and writing “Terminal”.
Using “git checkout” will make a new branch of files for you to work with. Making a new branch means you can make your changes as you like, without altering the main team’s files. If something happens that you don’t want to save, it doesn’t have to risk your team’s files, because it’s on a different branch. I’m still learning about how to merge branches.
3) Edit your files,
My text editor is Sublime Text. Most of us downloaded it in Ascend. When you open a file here and write in it, you are editing the code!
4) git add to the stage,
Typing “git add .” with a period at the end (as shown) will tell Git to track all the changed files in your current directory! That means that all the changes you have made (like additions and deletions) are just a step away from being committed as final!
5) Review your git status,
As you work with Git, “git status” will be your good friend! Lisa taught me that it’s important to check your git status often, to make sure that you’re only going to commit the changes you want, and to make sure that committed files have made it past the stage to the final production. As you type various commands, git status will be your road-map for what you’re doing.
6) git commit the changes,
Typing “git commit” will finalize your staged changes, making them ready to be sent on to GitHub!
7) Write a comment for your team,
Using the format of git commit -m “comment” will tell your project leaders why you made your commit.
8) Push to your fork!
A great way to figure out where your files can go is to type “git remote -v” into your Terminal. This will show you the symbolic name for your team’s main repo, as well as the symbolic name for your independent working version.
The format for pushing your modified files to your own working repo is as follows, without parentheses:
git push (repo name) (branch name)
For instance, “git push fruits orange” would push all the modified files in the orange branch into the fruits repo. As I’m working on my own independent copy of the fruits repo, I can update my repo by pushing my changes on the orange branch into my GitHub profile’s repo, fruits.
9) Log into GitHub,
10) Go to your profile,
You can click your own username to visit your profile page!
11) Find the team repo,
Click the team repo to view its files!
12) Make a pull request to send files up the tree!
When you’re looking at your forked copy of the team repo on GitHub, there’s a category button off to the right side of your screen:
When you click that category, you’ll see a button for creating a pull request!
You can also write comments to talk about your changes and how they can be included in the team’s files.
Again, these are basic steps, and the more in-depth tutorials online will provide extra details about troubleshooting. I hope this framework helps!
12 Sep 2014 »
The first week of Ascend has been a flood of information, and we’re learning as we go, but there’s a lot of catching up to do!
We’re each creatively multitasking to make contributions while learning different aspects of programming.
What’s great about the Ascend Project is that we’re all taking in the energy of the space, solving problems as they arise, asking questions, and taking care of business, as individuals and as a team. We are students. We are teachers. We are innovators. We are cheerleaders. We are friends. As Mozillians, we can fulfill each of these roles, and more! We can plan our goals, equip ourselves with the tools to succeed, and carry onward with the thoughtful support of our team.
It’s been a long time since I’ve had such a jam-packed schedule as I do with Ascend. I’ve become accustomed to independent projects, and my schedule has always been flexible. Making the 9 to 5 schedule each day has made me feel a little more sleep-deprived, but every time I walk to the office, I feel a rush of inspiration about the new day. In one short week, I have learned so much, and each day brings new challenge with new hope.
So far, I’ve learned how to use Vim, debugged the Evil Snowperson’s photo theft, explored the command line prompts, researched various topics for presentations, explored Mozilla’s latest innovations, solved problems with my classmates, contributed to the Etherpad, participated in several teaching moments, identified some bugs, and started designing an HTML page with Webmaker’s Thimble! Here’s the draft of my page (which I’ll need to improve when I can).
On Friday this week, we had an amazing Maker Party, where we paired up and researched resources from Mozilla Webmaker to teach back to the class.
Candida and I were tasked with exploring web navigation, and we were both quite intrigued by the concept of Filter Bubbles. Our curiosity about online tracking and “user customization” facilitated an amazing project where we deconstructed how websites often filter their feedback to the user, based on what the user has already done in the browser.
We asked everyone to use the same search engine and search for the same terms, and we found out that different people saw different search results!
When you type a search into a search engine like Google, the results you see will often be narrowed and focused based on your geographic location, other websites you have visited, and certain efforts made by companies to prioritize their search results over other results. It turns out that companies pay a lot of money to improve their chances of being near the top of the list in a search engine!
However, we discovered many ways for users to customize their settings so that they can see exactly what their connection is doing, and so that websites cannot track them. Several Ascenders presenting in our Maker Party (Thank you, Jessica, Peri, and Sofie!) encouraged us to utilize resources like the Mozilla Lightbeam add-on, The Tor Project, and private browsing.
When Candida and I presented to the group, I really appreciated that our talk about “escaping the filter bubble” related so well to the wisdom shared by our classmates in their presentations. We also had a wonderfully enriching discussion about net neutrality and writing to Congress!
During our presentation, a question arose: “Why would someone want to escape the filter bubble and see the web without customization?” Candida shared her compelling wisdom about how important it is to be aware of the impacts of our online activities, and how corporations respond to what we do online. There’s a lot of money, privilege, politics, and power involved, but it’s up to us to be informed about the outcomes of our decisions. Thank you, Candida! Your words continue to inspire us!
The internet is a vast, open resource, full of so much knowledge and wonder! When we can browse as independent users without the invisible restrictions imposed upon us by third parties, the doors to learning are wide open. That’s what open source education is all about!
If you’re looking for a search engine that doesn’t track you, try DuckDuckGo.com for more privacy!
Eli Pariser has also created a very helpful set of resources for escaping the filter bubble!
08 Sep 2014 »
People have often told me that computers were not for me. I was not “that kind of person” and programming was “too intense” for me to understand. Last week, I made a change in my life by believing that I could learn more, do more, be more, and change more.
I joined the Ascend Project.
We are 20 people (and many mentors strong!) with various backgrounds and experiences, coming together to learn as much as we can about programming. Our mission is to contribute to open source web materials in order to improve educational resources and web literacy wherever we can. As participants in the project and as new Mozillians, we cherish the thoughtful support of each of our teachers, and we are all grateful for the amazing resources Mozilla has offered us.
Thank you, Lukas, Kronda, Dino, Debbie, Katt, Shawna, and each of the Mozillians who have dedicated their time and energy to be part of these moments with us!
During our first day, we shared our expectations, hopes, and goals for what the project would look like. I was definitely nervous, and expecting a pop quiz in programming language, but I discovered that Day One was the Day of Strength. We took this day to create a community, empowering each other and providing support whenever needed.
After writing agreements for respecting each other (and ourselves) during the course, we were introduced to the StrengthsFinder assessment, created by the Gallup Strengths Center. We had 20 seconds to answer each question about our feelings and behaviors. It’s difficult to prioritize things with only 20 seconds! Each participant received a list of their Top 5 Strengths!
As an exercise in encouragement and empowerment, we discussed our Strengths in small groups, and came together to share what we learned. I learned a lot about personal strengths by listening to what other people received, and comparing those results to my own.
In the middle of reading my Strengths assessment, I felt like I was reading my own life, described on a piece of paper. Each one of the categories described my feelings and behaviors so accurately that I felt strongly encouraged to believe in my ability to succeed in Ascend. I also started crying a bit from the overwhelming sense that my emotions had been displayed before me in a way I could communicate to others.
My Top 5 Strengths are: Learner, Context, Individualization, Connectedness, and Relator. Each of these strengths empowers the others, and I love that I’ve found a way to explain my personality through these strengths.
One of my course goals is to share my Strengths with the combined Strengths of my fellow participants. We are forming a bond of learning which is changing us all.
To my amazement, we were invited to participate in the formal updates meeting attended by Mozillians around the world! Honestly, I didn’t comprehend most of the things that were said, because it seems like the systems and resources are so new to me. I don’t know these things now, but I will find out when I can.
Lunch was AWESOME! There was amazing, excellent, splendid kale salad! :) I also really appreciate the coffee flow…
We took a wonderful tour of the Mozilla office, as well (thanks, Katt!) and reflected on our first day together.
At the end of the day, I was somewhat confused, and very tired, but this is an amazing roller coaster ride!
I’ve known for a long time that I’ve wanted a long-term career in teaching, yet I also readily believed the people who told me that computers and computer science would forever baffle me. I was going through life just “accepting” the messages that this whole branch of information was completely distant from my experience, and impossible to understand. Mozilla thinks differently. Learning is everywhere!