We were short one team member today as Jason was out of town and unable to get back in time. We each looked for a few more bugs, just in case we couldn't replicate or figure out the bugs we picked last week.
Our team has managed to replicate a bug today (Bug #12653). We found a bug that deals with Blu-Ray issues (Bug #12594), and since I have Blu-Ray built into my laptop we will be able to look at this one as well.
Wednesday, February 29, 2012
Exploring opensource.com
Today's assignment was to go read and discuss two articles from opensource.com. I chose "How to teach undergrads how to become open source contributors without writing any code" which is about a class full of college students learning to become functional open source contributors without having to write code (redundancy here due to the title I know. Sorry about that), and "Culture eats strategy" which is about why understanding a company's culture is so important. Let's get to it, shall we?
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
Sunday, February 19, 2012
2/19/2012
We had our weekly group meeting today at 2 (our group decided to make them a weekly thing today). We have been working on a timeline for the class project and creating milestones. We've decided to work on at least three bugs, one every two weeks, instead of working on one major bug for the rest of the semester. The interval was chosen so we would be able to fix our first bug before spring break. We discussed various bugs that we found on the bug tracker, and selected five bugs to try and fix this semester.
Tuesday, February 14, 2012
2/15/2012
The assignment for this post was to read chapter 4 in Software Development: An Open Source Approach. This chapter covers Software Architecture. The book describes software architecture as being "an organizational model for a moderate or large software system...provides strong guidance on how modules interact with each other, how a test suite can be designed, how refactoring strategies can be exercised, and how program bugs can be detected and removed."
It lists 4 architecture patterns:
It also lists the 3 important software architecture development principles:
It lists 4 architecture patterns:
- Mutlti-Tier: distiguishes the user interface layer from the core class layer from the database later. GUI components are isolated within the user interface layer and database interactions are isloated within the database layer.
- Client-Server: separates the functionality of a typical user of the system from that of the server that hosts the database that all users access. The "client-side" code is that which resides on the user's computer, including GUI components. "Server-side" code resides on the server's computer, including the database components.
- Transaction Processing: useful for systems that accept a stream of transactions and process each transaction fully before moving on to the next.
- Model-View Controller (MVC): useful for systems that have substantially complex user interfaces. The idea here is to separate the functionality that underlies the user interface from the code that controls how the user sees and interacts with the system.
It also lists the 3 important software architecture development principles:
- Layering Principle: Every module belongs in a single layer. No module should skip over its neighbors in the layer immediately above or below it, in order to provide or obtain services from another layer.
- Maximum Cohesion Principle: All the functions that relate to a single concept are gathered into a single module or class. A software architecture is maximally cohesive if all its modules and classes are cohesive in this way.
- Minimum Coupling Principle: Two modules are coupled if either one shares information or receives services directly from the other. A software system is minimally coupled when the number of interactions between all pairs of modules is kept to a minimum.
Sunday, February 12, 2012
Group Meeting--Fixing a Bug
Our group met today at 2 to work on the group assignment due this week--fixing a bug in the project. We had already established what we wanted to work on. David found a bug a couple of weeks ago (bug #12565) that dealt with the incorrect display of images in slideshow mode. He created a test image for the developers, but no one was able to replicate the bug. We decided to fix the README.ubuntu file, which has some incorrect links and is missing some of the dependencies needed to get the source code for XBMC.
Friday, February 10, 2012
2/10/2012 (TOS Chapter 7)
This chapter covers patches, and how to create and submit them. We were asked to do exercises 7.2.2, 7.8, and 7.9.
To do exercise 7.2.2, the authors want you to create the file used in the example to compare the outputs of a diff command using the -u flag and without it. The file is a simple "Hello, World" program, very simple to write (just copy and paste into the text editor). I booted up Ubuntu--I prefer it for my homework in this class because that's the OS we have to use for our projects--and opened up my text editor (gedit) so I could get the program pasted in and saved the file. I then opened up the terminal window and followed the instructions in the example, which I needed to do before completing the actual exercise. With that taken care of, I started playing with the diff command as stated in the exercise. I noticed that without the -u flag, the only output to my terminal window is the original line of the program and the new one that contains the change. When the command has the -u flag, the output shows where AND when the change was made. It even prints out the program text with the original and new lines of code--a "-" for the line that will be replaced and a "+" for the new line of text that will be going into the program. After seeing the outputs for both versions of the diff command, I prefer the one with the -u flag because it contains more information, but I suppose that doing the command without the flag would be more efficient if you have a lot more going on in your terminal window. I prefer it because I like to know exactly where it is being changed. On to the next!
7.8:
This exercise says to create a patch file that represents a new file, foo being with the contents bar. I'm little confused by this one actually. I wasn't sure if we were supposed to create a patch for the hello.c files or if it was for a different program. Maybe I'm just being an idiot, I don't know. Let's hope the last one goes better...
7.9:
This is a step-by-step exercise that wants you to create a patch echo for a project. I actually really like this one because I'm a Windows user, so I don't know a whole lot about the bash commands except for what I used last semester in CSCI 362. Unfortunately, my terminal keeps telling me that the commands I'm trying to use aren't correct, and typing exactly what TOS is telling me to type in the exercise. I don't understand why this is happening. I did read through the exercise and I'm pretty confident that I understand what's going on. It's basically a reinforcement of the two previous exercises along with teaching the new concept of creating a working echo binary.
To do exercise 7.2.2, the authors want you to create the file used in the example to compare the outputs of a diff command using the -u flag and without it. The file is a simple "Hello, World" program, very simple to write (just copy and paste into the text editor). I booted up Ubuntu--I prefer it for my homework in this class because that's the OS we have to use for our projects--and opened up my text editor (gedit) so I could get the program pasted in and saved the file. I then opened up the terminal window and followed the instructions in the example, which I needed to do before completing the actual exercise. With that taken care of, I started playing with the diff command as stated in the exercise. I noticed that without the -u flag, the only output to my terminal window is the original line of the program and the new one that contains the change. When the command has the -u flag, the output shows where AND when the change was made. It even prints out the program text with the original and new lines of code--a "-" for the line that will be replaced and a "+" for the new line of text that will be going into the program. After seeing the outputs for both versions of the diff command, I prefer the one with the -u flag because it contains more information, but I suppose that doing the command without the flag would be more efficient if you have a lot more going on in your terminal window. I prefer it because I like to know exactly where it is being changed. On to the next!
7.8:
This exercise says to create a patch file that represents a new file, foo being with the contents bar. I'm little confused by this one actually. I wasn't sure if we were supposed to create a patch for the hello.c files or if it was for a different program. Maybe I'm just being an idiot, I don't know. Let's hope the last one goes better...
7.9:
This is a step-by-step exercise that wants you to create a patch echo for a project. I actually really like this one because I'm a Windows user, so I don't know a whole lot about the bash commands except for what I used last semester in CSCI 362. Unfortunately, my terminal keeps telling me that the commands I'm trying to use aren't correct, and typing exactly what TOS is telling me to type in the exercise. I don't understand why this is happening. I did read through the exercise and I'm pretty confident that I understand what's going on. It's basically a reinforcement of the two previous exercises along with teaching the new concept of creating a working echo binary.
Tuesday, February 7, 2012
2/8/2012 (TOS Chapter 6)
For this post we are to do exercises 6.4, 6.5, 6.6, and 6.7 from chapter 6 of "Teaching Open Source".
6.4:
The oldest bug I could find was #5231 (DVD Player: Certain AVI-files play too slow/fast after seeking forward/backward). This ticket was first created 3 years ago and is still an unresolved problem (it was last modified 3 weeks ago). The bug here doesn't seem to be occurring on a consistent basis, which is a problem when debugging software and is probably the reason why this one hasn't been fixed yet. I can't think of a solution to this bug. No bonus points for this chica. (Insert Debbie Downer sound clip here).
6.5:
This is something that I had already done before the assignment because you have to have an account to get into the forums. Can I get bonus points for that one? (Don't look at me like that. A girl can dream, you know.)
All kidding aside, you have to have an account to contribute in any way to the XBMC project, and each member of our group registered in the forum community before we began looking at the bug tracker.
6.6 and 6.7:
I could not do these two exercises because my VirtualBox screwed up somehow. Lovely. Just lovely. Thank the Lord I remember how to install it.
**NOTE: Something's wrong with the Blogger tonight, so I had to highlight the bulk of this post in black so I could read it. If it changes back to normal later, I will fix this post.
6.4:
The oldest bug I could find was #5231 (DVD Player: Certain AVI-files play too slow/fast after seeking forward/backward). This ticket was first created 3 years ago and is still an unresolved problem (it was last modified 3 weeks ago). The bug here doesn't seem to be occurring on a consistent basis, which is a problem when debugging software and is probably the reason why this one hasn't been fixed yet. I can't think of a solution to this bug. No bonus points for this chica. (Insert Debbie Downer sound clip here).
6.5:
This is something that I had already done before the assignment because you have to have an account to get into the forums. Can I get bonus points for that one? (Don't look at me like that. A girl can dream, you know.)
All kidding aside, you have to have an account to contribute in any way to the XBMC project, and each member of our group registered in the forum community before we began looking at the bug tracker.
6.6 and 6.7:
I could not do these two exercises because my VirtualBox screwed up somehow. Lovely. Just lovely. Thank the Lord I remember how to install it.
**NOTE: Something's wrong with the Blogger tonight, so I had to highlight the bulk of this post in black so I could read it. If it changes back to normal later, I will fix this post.
Sunday, February 5, 2012
2/6/2012
Our group met today at 2 to discuss where we were individually and fix a bug. At this point, everyone has the XBMC source code compiled and working, and almost all of us are in members in the forums (I just got in today) on the XBMC website. I had to create a new Ubuntu OS in my VirtualBox before I could get mine, which takes a while because of all the updates and length of the installation process when run through VirtualBox. Many, many thanks to Jimmy and Matthew for all of your help with my getting the source code downloaded and compiled. :)
The original plan was to fix a bug in the README file of the code as the bug to fix and submit for the class. This plan fell through when we discovered that someone else had already fixed it. (Insert disappointed sigh here). The team split up, with some of us looking at long-term fixes and the others looking for short-term for next week.
Our group is getting along well thus far. There's definitely a relaxed vibe among the members, and we don't have any personality clashes. This great group dynamic is making this a fun project for me, and hopefully for the others as well.
Friday, February 3, 2012
Reflection: Magazine Article
My previous post was a reflection on an essay chosen by Dr. Bowring for us to read and discuss. This time he let us choose what we wanted to read and review. He passed out some magazines and asked us to find an article that interested us for this assignment. I picked up a copy of IEEE Software and found an interesting article right off the bat about software components in cars. I read it, and then I saw the title of the article right after it and I knew I was not going to be writing this post about cars. Instead, I chose an article about mobile applications. Let me explain why. I'm also taking CSCI 360: Software Architecture and Design where, like this class, we have to do a group project. The group that I'm in has decided to make a mobile app, and when I saw that article I just had to read it.
The article is "Development Platforms for Mobile Applications: Status and Trends" by Damianos Gavalas and Daphne Economou from the University of the Aegean. In it, the authors break down and compare the four most popular runtime environments used for "resource-constrained mobile devices"--Java Mobile Edition, .NET Compact Framework, Flash Lite, and Android--by looking at earlier research, technical specifications, white papers, an informal survey of 32 mobile-application developers with hands-on experience using the four platforms reviewed, and even creating their own app to run implementing each runtime environment to showcase the advantages and disadvantages of each one. I really like that they created an mobile app to test each one. It shows that they wanted to be able to contribute their own opinions to the article, not just what the other developers had to say. So let's take a look at each one as they broke it down....
Java Mobile Edition (ME)
Java ME is a subset of the Java platform that contains a certified collection of Java APIs for developing software for resource-constrained devices like cell phones, PDAs, and set-top boxes. Its features are:
- It runs on top of the kernel-based virtual machine (KVM), which allows for reasonable, but not complete, access to underlying device's functionality
- Supports cross-platforms through configurations and profiles, and was designed to be cross-platform. This is done by having specification and implementation as two separate processes
- By targeting individual operating systems, developers using Java ME have access to a large set of well-defined and mature Java Specification Requests (JSRs)
- The Java Language motto "write once, run anywhere" doesn't apply here. Developers must provide slightly different application versions to address variations in JSR sets and implementations across a wide range of device capabilities and choice of profiles, configurations, and APIs. This often results in something called device fragmentation, where dozens of executables for a given title have to be written. This increases the operational costs over the product's life cycle, restricts the devices that Java ME apps can reach, and is overall more suitable in apps that target devices with similar capabilities and Java API support
.NET Compact Framework (CF)
This runtime environment was designed for applications on Windows Mobile. It is a subset of Microsoft's full .NET platform that preloads the Common Language Runtime (CLR) engine in the device's memory to facilitate mobile-application development. Its features are:
- .NET CF runtime is analogous to the Java Virtual Machine (JVM). Instead of writing native code for the underlying device's operating system, .NET developers write managed code, which targets a managed execution environment
- .NET CF user interface design is based on a rich subset of .NET Windows Forms
- Comparable to Java ME with respect to providing a managed runtime environment, rich libraries and components for reuse. It has advanced user interface components, network connectivity, data management, XML Web services, in addition to familiar APIs from the full .NET framework, such as Windows Forms control. These features ease the transition for desktop developers to mobile apps.
- It is "language-agnostic" and simplifies the Common Intermediate Language (CIL) instructions.
- Demonstrates API-level consistency and compatibility with the full .NET platform. This has had unforeseen memory footprint costs, but the .NET CF nevertheless represents a fast-paced implementation driven by a powerful vendor
- Offers satisfactory integration with device-specific functionality. It doesn't exhibit Java ME's fragmentation problem. .NET CF targets a limited set of Windows end devices, and the VS.NET development tools include license costs
- It restricts the operating system support to Windows platforms, which represent only a small part of today's mobile device products
- Core components are a subset of the full .NET framework, and it only has about 30% of .NET's classes and functionality. Some of the classes exist in both .NET and .NET CF, but the .NET CF version doesn't necessarily support all the full version's class members (like properties, methods or events). Many classes aren't implemented at all, and others are only partially implemented. Unique .NET CF classes address device-specific and third-party extensions
Adobe Flash Lite
Flash Lite is a "propriety technology" that is popular as a multimedia and game programming platform. It was created specifically to help vendors to rapidly deploy rich content and interactive interfaces to mobile devices. Its features are:
- Stores its contents and GUI description in the vector-based SWF graphics and animation format
- Implements its application and presentation logic in ActionScript
- A Number of original equipment manufacturer (OEM) operator and developer adapters, which is increasing rapidly worldwide
- Flash Lite 1.1 supports Flash 4 and ActionScript 1.0, Flash Lite 2.0 and 3.1 support ActionScript 2.0. Both Flash Lite 2.0 and 3.1 are based on Flash Player 7 and 9, respectively.
- All versions support the World Wide Web Consortium (W3C) Tiny standard
- Is a reasonable choice for graphics-intensive phone and PDA applications
- Rapid development is a primary benefit. Developers skilled in Flash for desktop applications can easily switch to Flash Lite for mobile applications. Its easy to learn and easy to migrate Flash applications, and it includes a rich set of designer/developer tools. It offers rich media support (images, sound, video, animation), a relatively broad runtime installation base, and small deployment files based on vector graphics
- Isn't suitable for developing full-fledged stand-alone applications, mainly because it lacks the powerful mobile-oriented APIs of Java ME
- Exhibits poor graphics performance, partly because of the complex processing required for vector graphics
- Ships with an extensive toolset, but the toolset requires a license fee
Android
Android, which currently has the largest developer and deployment bases, was launched in 2007 by Google to advance open standards for mobile devices. It is an Apache free-software platform with an open source license for mobile devices based on Linux. It features:
- Written in Java and compiled in Dalvik executable (DEX) format. Each application executes its own process, with its own instance of the Dalvik virtual machine (DEX files are more compact and efficient than class files)
- Full access for developers to all the frameworks and APIs that the core applications use and to Google-developed software libraries
- Android software development kit (SDK) supports authoring applications with rich functionality
- Supports a relatively large subset of the Java Standard Edition (SE) 5.0 library. This implies reduced migration cost from Java desktop applications
- Supports several third-party libraries
- Similarly to Java ME, application development is powered by popular Java integrated development environments (IDEs)
- Provides inherent support for modular service-oriented applications and interapplication communication
- New platform releases, while great for introducing new user and developer features, raise fragmentation concerns. The platform's openness in the targeted device stacks aggravates the fragmentation problem
So after implementing the app on each platform, the authors found that the .NET CF and Android applications were easier to develop because of their improved compatibility with the full .NET and Java SE frameworks.
Wednesday, February 1, 2012
Reflection: "The Cathedral and the Bazaar"
Our assignment for the first of February was the read The Cathedral and the Bazaar by Eric Steven Raymond. For those of you who have never heard of this essay, it's about closed versus open-source software and Raymond's journey through the creation of an open-source project called Fetchmail.
First off, I would like to say that I really enjoyed reading this essay. The way it was written seems quite similar to what Dr. Bowring is asking us to do for this class, which is to write this blog and use it to publish our experiences during the semester. If you read it online as I did, you can see a revision history for the essay (the last revision was done 11 years ago). I liked being able to see that because it shows that Raymond really did go through the development process. He didn't simply publish an essay and leave it alone. He went back, maybe cleaned it up a bit, added to it--not unlike what programmers do with coding in open-source projects.
In the essay, Raymond gives 19 rules or lessons that he learned along the way about developing open-source projects. Since there are so many, I'm only going to share the ones that struck me the most (although you should go read the essay to find out about the rest).
1. "Every good work of software starts by scratching a developer's personal itch."
Think about it. Every little program, piece of software, application--all the popular ones anyway--are the result of a developer's personal itch. Why are they so popular? It's simple: the good works of software shows in the effort put into the coding. When the program is something that you know will be beneficial to your needs (and then possibly the needs of others) you put more time and effort into what you're doing, and it shows.
5. "When you lose interest in a program, your last duty is to hand it off to a competent successor."
This one seems like a no-brainer to me. As a developer, even if you lose interest in a program you will still want to see it succeed. After all, you helped bring it to life. It's only natural to want to find someone capable of carrying on in your place. If the next developer isn't competent the program dies. Simple as that.
8. "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."
This rule was one Raymond dubbed "Linus's Law" after Linus Torvald, the software engineer who initiated the development of the open-source Linux kernel. The author described it as follows:
"In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."
Basically, Raymond says it has the Delphi Effect--"the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers". This is also the principle behind Wikipedia and why it has thrived and grown in popularity.
First off, I would like to say that I really enjoyed reading this essay. The way it was written seems quite similar to what Dr. Bowring is asking us to do for this class, which is to write this blog and use it to publish our experiences during the semester. If you read it online as I did, you can see a revision history for the essay (the last revision was done 11 years ago). I liked being able to see that because it shows that Raymond really did go through the development process. He didn't simply publish an essay and leave it alone. He went back, maybe cleaned it up a bit, added to it--not unlike what programmers do with coding in open-source projects.
In the essay, Raymond gives 19 rules or lessons that he learned along the way about developing open-source projects. Since there are so many, I'm only going to share the ones that struck me the most (although you should go read the essay to find out about the rest).
1. "Every good work of software starts by scratching a developer's personal itch."
Think about it. Every little program, piece of software, application--all the popular ones anyway--are the result of a developer's personal itch. Why are they so popular? It's simple: the good works of software shows in the effort put into the coding. When the program is something that you know will be beneficial to your needs (and then possibly the needs of others) you put more time and effort into what you're doing, and it shows.
5. "When you lose interest in a program, your last duty is to hand it off to a competent successor."
This one seems like a no-brainer to me. As a developer, even if you lose interest in a program you will still want to see it succeed. After all, you helped bring it to life. It's only natural to want to find someone capable of carrying on in your place. If the next developer isn't competent the program dies. Simple as that.
8. "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."
This rule was one Raymond dubbed "Linus's Law" after Linus Torvald, the software engineer who initiated the development of the open-source Linux kernel. The author described it as follows:
"In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."
Basically, Raymond says it has the Delphi Effect--"the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers". This is also the principle behind Wikipedia and why it has thrived and grown in popularity.
Subscribe to:
Posts (Atom)