tmblrofji-blog

[tmblrofji-blog]

Update 4/24

Previous PR with distance/dot/cross: https://github.com/AnalyticalGraphicsInc/cesium/pull/5040

Current ticket for normal shading: https://github.com/AnalyticalGraphicsInc/cesium/issues/5152

PR for normal shading (see post below): https://github.com/AnalyticalGraphicsInc/cesium/pull/5228

=======

What did you accomplish this week? If you did not accomplish everything you intended, why not?

I was really hoping to finish the latest ticket, especially since this week is our last week, but I did not get to. I had starting reading the code in depth last Monday, and had asked Sean some questions in the issue’s thread. (Issue thread here: https://github.com/AnalyticalGraphicsInc/cesium/issues/5152). He had originally advised that I implement a normalShading option in a similar manner as backFaceCulling, but I was confused on two things. One, from the source code it seemed as if there were two variables for backFaceCulling: backFaceCulling and _backFaceCulling, and I wasn’t sure if there was a significance to this and whether it should be taken into account when creating the normalShading variable. Two, Sean had marked a line in which shading is applied, but the line was blank so I wanted to clarify whether the code that does the shading was specific lines below the marked one. While waiting for his response, I played around with the code, and tried writing unit tests to see if my code would work, but none of the unit tests passed (this could either be because my implementation was wrong or the unit tests themselves were written incorrectly, it took a while for me to learn how the unit tests themselves worked). But I didn’t get a response from Sean by the deadline, and I hadn’t figured out a solution on my end. I did create a PR anyway with a couple lines that initializes the normalShading boolean variable; that is linked above. I did manage to have my code for the previous ticket to pass the build tests; after last week’s meeting I noticed that even after fixing indentation/spacing, my code was suddenly failing the build tests, but I fixed it so that it now passes.

What are you planning on doing in the coming week?

I would have really liked to finish the shading issue, but I know that we technically won’t be graded on any more of our work after this week’s meeting. I also have other academic obligations as the end of the term approaches, but if I were to get help on the questions I had asked in the ticket, then I would like to attempt to work on it on my own time - more so as a personal challenge.

What might get in your way of doing it?

It’s hard for me to move forward without some guidance/clarification on my questions. We shall see if I’m able to figure it out, possible on my own time?  

[tmblrofji-blog]

Readings 4/24

Assigned Reading(s): (Ashe Dryden) : https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community Readings I found: (Hacker Factor Blog): https://www.hackerfactor.com/blog/index.php?/archives/415-Open-Source-Sucks.html (Mark Tarver): http://www.shenlanguage.org/lambdassociates/htdocs/blog/the_problems_of_open_source.htm ==== I read this week's article by Dryden before finding two other articles about criticisms of FOSS, and it wasn't until I read through the two articles I picked that I realized how much more interesting Dryden's arguments were. Most of the articles that I combed through when searching for "criticisms of FOSS" merely mention disadvantages and/or flaws of open source software, but none of their arguments weren't convincing for me. In my opinion, if FOSS is that evil, then you simply don't have to get involved; whether you participate in FOSS in your choice. But Dryden suggests that there really isn't that much of a choice as I thought; she argues that there is an unspoken (or spoken?) pressure for programmers to get involved in open source. Open source, and the programming world in general, largely works on the basis of a meritocracy, where your value rises in proportion to your contribution, so those who don't contribute as much are of lesser merit. So if you want to prove your skills as a programmer for a job or another important situation, you need to show your contributions to open source, and lack of contributions damages your credibility as a developers. Yet those who don't contribute as much may not be able to because they simply don't have as many opportunities to contribute (possibly because of their background), or may not even be allowed to share their work. This argument was interesting to me because it challenged the way I viewed participation in FOSS. To me, getting involved in FOSS should be completely voluntary. Sure, you may be motivated by the opportunity to improve future employers with your contributions to FOSS projects, but part of the beauty of FOSS is choosing not only whether or not to participate, but how to participate (implementing new features vs. writing tests vs. improving documentation, etc.). But I agree with Dryden in that there is a sense of meritocracy in the programming world, including open source, which puts those who don't get inolved at a huge disadvantage. Like Dryden mentions, not all who don't contribute don't want to; they may simply just not be able to contribute as much because of their circumstances. In addition, I also think that there are skilled programmers who simply don't want to get involved, yet are overlooked as candidates because they don't have many open-source contributions to show for themselves. Programmers (and even non-programmers) should be able to choose whether they want to get involved in open source, and should have the freedom to demonstrate their skills in ways other than open source contributions when applying for jobs. The other two articles I found had more overlap with each other than they did with Dryden's; primarily, both argue that the quality of FOSS projects fall short compared to proprietary code. There was one shared sentiment between Tarver's essay and Dryden's article that stuck out to me: investors and corporations benefit from open source development far more than the developers themselves. Not only are corporations able to use some of best ideas and code open source projects offer freely without recompense, but they can continue to profit greatly and give little financial support back as long as developers continue to invest their own time in their contributions without pay. Whether this argument is strong or not depends on how important profit (and who that profit goes to) is to the open source developer, but I imagine for a good number of those in open source would find this to be fairly convincing.

[tmblrofji-blog]

Update 4/17

Issue with distance/dot/cross: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865)

Pull request: https://github.com/AnalyticalGraphicsInc/cesium/pull/5040

New issue: https://github.com/AnalyticalGraphicsInc/cesium/pull/4759

What did you accomplish this week? If you didn’t accomplish everything you intended, why not? Sean didn’t get back to me about my fixes in indentation/etc. from my distance/dot/cross implementations until after last week’s meeting, but he responded with a couple more fixes in my spacing/styling and also asked me to include shader expression tests for those functions. Those I got done.

After that, I moved on to looking at the new issue; it took me a while to understand the code and I’m still playing around with it. I tried a couple different implementations but I’m trying to figure out how to test it beyond just writing tests. I haven’t made a pull request yet.

Approximately how many hours did you spend working on your project? About 30 minutes to fix indentations and add shader expression tests in previous ticket. About 3-4 hours were spent on the new ticket (reading the code, trying to understand it, playing around with different implementations).

What are you planning on doing in the coming week? I would like to finish this ticket by next week since that is our last meeting.

What might get in your way of doing it? I am still slightly confused on how it works, so I may ask Dylan at today’s meeting for any pointers/if he has worked on this kind of ticket and can give me advice.

[tmblrofji-blog]

Readings 4/17

Readings:

(de Silva) http://timreview.ca/article/399

(Paul) http://www.slate.com/articles/technology/future_tense/2014/09/hfoss_software_for_humanity_computer_science_students_solve_real_world_problems.html (Wolff - found for this week’s readings) http://johnwolff.name/tag/humanitarian-foss/

======

This week's readings were by far the most enjoyable, mostly because they reminded me of my prior academic experience prior to studying computer science. I majored in Economics in undergrad with a focus on International Development, and my senior thesis was on the impact of Information and Communication Technology on Economic Growth - I reviewed emerging studies on how technological developments such as mobile apps were affecting economic growth in developing countries. Such mobile apps in these studies were very similar to the ones that students developed in Paul's article, and though the results of my thesis found the effect of such apps inconclusive, I'd like to think that advancements by projects like HFOSS have changed this. I readily agree with many, if not all, of the reasons Paul lists of how students can benefit from getting involved in FOSS: helping students learn more about the true nature of programming and providing experience on submitting code and documentation by certain deadlines were a couple of my favorites. I think the most convincing though is provided by Wolff, in that HFOSS simply has intrinsic purpose; students hardly have to wonder what the code they write has to do with them, because they know it has everything to do with helping people alleviate their suffering. I read de Silva's article before Paul's, so one major concern I had when reading Paul's article was regarding the quality of the students' submitted code. I agree with de Silva in that with HFOSS projects, there really is no room for error - the product cannot afford to fail when providing its services in disasters. I don't intend to dismiss the skills college students possess, but it seemed a little risky to leave the development of HFOSS projects to students who are still learning their trade. But I was much more assured when reading in Paul's article that teams at projects like Sahana revew the code before including them into the system; that makes much more sense and aligns very much with the spirit of open-source. What was most interesting was the ways in which open source aligns with humanitarian values. In particular, the values of not discriminating by access and of empowering local capacity are highly regarded in humanitarian issues. I used to work for a humanitarian non-profit organization that trained women in rural areas of Indonesia how to sew and sell handmade bags. The organization also provided workshops that taught women how to run their own businesses, and encouraged them to find ways to make their businesses best work for their needs. Anyone in the villages was welcome to learn; there were no restrictions or fees. I never noticed that these values of non-discrimination, open access, and empowerment to local capacity are also found in FOSS; anyone and everyone can participate in open source, and developers are encouraged to modify source code in ways that best benefit their needs. Recognizing these kinds of connections is, for lack of a better word, cool; it makes me appreciate FOSS much more.

[tmblrofji-blog]

Updates 4/10

At last week’s meeting, I was still resolving my unit tests with distance/dot/cross, and planned on finishing those this week so I can move on to the next ticket.

Issue with distance/dot/cross: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865)

Pull request: https://github.com/AnalyticalGraphicsInc/cesium/pull/5040

New issue: https://github.com/AnalyticalGraphicsInc/cesium/pull/4759

What did you accomplish this week? If you didn’t accomplish everything you intended, why not? I finally figured out what was wrong with my unit tests; it was a mixture of my implementation of cross as well as how I was writing my tests. Those were resolved, and I also refactored the code slightly (essentially I moved a lot of code I had written inside the getEvaluateBinaryFunction to the distance/dot/cross declarations). There were some merge conflicts I had to resolve but it did not not take nearly as long as I expected. I also did some changes to spacing/indentation per Sean’s request. I was able to read through the new ticket but haven’t actually started coding anything.

Approximately how many hours did you spend working on your project? About 1.5 hours to fix my unit tests, refactor the code, and resolve merge conflicts/fix indentation and spacing. I spent another hour reading through the new ticket.

What are you planning on doing in the coming week? I’m hoping to make some solid progress in the new ticket this week. I also might have to make changes if Sean suggests any to the PR I just finished.

What might get in your way of doing it? The final project for 455/555 has started............... #timemanagement

[tmblrofji-blog]

Readings 4/10

Readings:

(Michael Williams) http://www.drdobbs.com/open-source/building-and-maintaining-an-open-source/240168415

Readings I found for this week:

(Producing OSS, Communication channels): http://producingoss.com/en/getting-started.html#communications-channels

(Producing OSS, Chapter 6 Handling Growth): http://producingoss.com/en/growth.html

===

A theme that runs through both last week's and today's readings is the importance of communication in an open-source community. Last week's readings stressed the importance of having a clearly-defined vision for the project and making sure that developers are on board with that vision. This week's readings also mention this, yet Williams in particular suggests that much more needs to be communicated to developers. Open-source projects need to make it easy for developers to be informed about various milestones and roadmap, the software's design and APIs, and the process in which developers can participate and commit; they should also be provided with online resources such as tutorials and code examples to further help their understanding of the project. Williams also highlights other kinds of relationships within the open source community that are also in need of clear communication. In the beginning stages of a open source community, internal support needs to be able to help community members when they run into bugs and undocumented features before developers can gain enough experience for them to answer those kinds of questions for newcomers. The community manager must help the executive sponser, if there is one, to understand the project's plan and value, and how it will affect their business. Projects should be in communication with other open-source developer communities, so both can benefit from "piggybacking on [each other's] momentum" (Willliams). The project should also be communicating different incentives for their advocates, such that they would be encouraged to contribute either by promoting the project via social media or actually committing changes in code in exchange for awards and recognition. Though I haven't had much experience working in open source prior to this semester, I am convinced that this running theme of communication is indeed important to the development of open source communities. I say this from my initial experience with starting with CesiumJS. I think CesiumJS does a great job in providing starter/example code and tutorials, along with documentation on how to start contributing. But a couple things that I either couldn't find or weren't really flushed out out were milestones (it's hard to tell what general direction the community is going, what things they want to accomplish during different points of the year, etc.) and the fact that there was just one Google forum for questions rather than having separate forums for users and developers respectively (this is discussed in the Communication Channels section of the Producing OSS resource). The latter was more confusing for me, because though that forum is available, not all questions get asked there; developers seem to ask questions directly in their pull requests as well. It also seems inefficient in how the forum doesn't have sections where askers can categorize their questions, which would make it a lot easier to take advatange of archives as described in Chapter 6 of Producing OSS - if archives were organized well, it could prevent the community from posting duplicate and possibly outdated information. By making milestones clearer and more advertised, the community would benefit from a more focused sense of direction, and by having an extended, more structured forum(s), developers would be able to relay their questions to the right people, and strengthen the teamwork of the entire community.

[tmblrofji-blog]

Update 4/3

At last week’s meeting, Dylan and Jane pointed me to another issue that Jane and I would be working on after distance/dot/cross was finished. More details on what I was & was not able to accomplish this week covered below...

Issue with distance/dot/cross: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865)

Pull request: https://github.com/AnalyticalGraphicsInc/cesium/pull/5040

New issue: https://github.com/AnalyticalGraphicsInc/cesium/pull/4759

What did you accomplish this week? If you didn’t accomplish everything you intended, why not? In short, I was not able to accomplish as much as I had hoped to this week. I was hoping to finish distance/dot/cross this week and fix the tests, and while I found out why my tests weren’t passing, I belatedly realized that I might have to refactor in order to resolve merge conflicts with Jane’s implementations of other binary functions, and haven’t been able to finish those by today. Because of this, I also wasn’t able to look at the new issue that Sean gave me last week.

Approximately how many hours did you spend working on your project? About 1 hour to resolve why my tests weren’t passing, and have now been spending another hour and a half refactoring so that I can resolve merge conflicts with Jane.

What are you planning on doing in the coming week? I’m not entirely sure if I’m completely responsible for resolving merge conflicts with Jane’s implementation, or if I should just focus on finishing my implementations of distance/dot/cross. So after I ask Dylan at today’s meeting, I will finish those and move on to the new issue.

What might get in your way of doing it? I’m not sure how much time it will take to resolve merge conflicts, if that is what I’m responsible for.

[tmblrofji-blog]

Readings 4/3

Articles: (Rich Gordon): http://mediashift.org/2013/08/6-things-to-know-about-successful-open-source-software/ (Matt Asay): http://mediashift.org/2013/08/6-things-to-know-about-successful-open-source-software/ (Ashley Baldwin): https://wpdistrict.sitelock.com/blog/the-open-source-community-wordpress-key-to-success/ (*Article I found for this week’s readings)

It's interesting that the characteristics Gordon argues are essential to the success of an open source project differ greatly from the ones that Asay accredits to Red Hat's success. Gordon does not mention anything regarding the complexity or the drive of innovation of a project, yet that is what Asay says is what made Red Hat the "poster child" of open source. With a lack of overlap between the two articles, it's hard to say which characteristics I'm most convinced are important to the success of an open source project, and it becomes even more difficult when I consider the article I found for this week's readings about WordPress. But there is one overlap with the suggestions in Gordon's article and Wordpress' success that did catch my eye. That overlap, which Gordon points out, is having a clearly defined set of users who are also developers of the software. WordPress allows users to customize their blogs to fit their needs, without having to follow any specific guidelines or work within certain licenses. The organization also gives users different ways to contribute to the platform, which includes "developing PHP, creating and uploading plugins or designing themes". The users' need is clearly met by the software, and the platform makes it easy for users to give back through various kinds of contributions. For RedHat, Asay does mention that a successful open source project involves an increasing number of developers, but their influence is far more indirect than what is demonstrated by the users of WordPress (and Gordon even argues that the number of developers have no bearing on the success of an open source project). From the examples of RedHat and Wordpress, I find it difficult to believe that there is just one single recipe for success for an open source project. WordPress works well because it addresses a user-centered need yet encourages the contributions of their users, but clearly RedHat also succeeds by what Asay reasons is because of the complexity of its product. If there truly isn't one single recipe for success, that may be encouraging for many open-source projects who strive to achieve the same level of success as projects like Red Hat and Wordpress, but this also could be discouraging in that such projects would have to go through many seasons of trial and error to achieve their goals.

[tmblrofji-blog]

Updates 3/27

At last week’s meeting, I was able to figure out my problem with pushing my new changes to distance (thanks Dylan and Jane!); I managed to get my implementation of distance and corresponding tests pushed to the PR, and Sean approved. At the meeting we agreed that I would be responsible for implementing dot and cross.

Issue: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865)

Pull request: https://github.com/AnalyticalGraphicsInc/cesium/pull/5040

What did you accomplish this week? After getting Sean’s approval for distance, I worked on implementing dot and cross; they are similar to distance in that they are geometric functions, so implementing them was pretty straightforward. I also wrote tests for both functions.

Approximately how many hours did you spend working on your project? About 1 hour to write the dot and cross implementations, and another hour to write the tests. The tests I wrote did not work, so I spent another hour trying to resolve them (see answer to the following question).

If you didn’t accomplish everything you intended, why not? Though I did implement dot and cross and their respective tests, some of the tests are not passing; my tests for checking for mismatching inputs (e.g. all three functions should take inputs that are the same, like two vec2s or two vec4s), and my test for calling cross do not work. If I had more time, I would have been able to figure these out by tonight, but I had a 555 assignment that I needed to spend time working on this past week.

What are you planning on doing in the coming week? Fixing my implementation to make sure the tests pass. After I get the tests to pass and Sean’s OK, I will probably work on whatever Dylan says Sean wants us to tackle next.

What might get in your way of doing it? I think Sean mentioned that there might be some merge conflicts with my implementation of the three functions, so if those are substantial I might need some time to resolve those.

[tmblrofji-blog]

Readings 3/27

This Week’s Readings:  Chris Meier, https://handsontable.com/blog/articles/5-successful-business-models-for-web-based-open-source-projects

Paul Rubens, http://www.cio.com/article/2944334/open-source-development/why-the-open-source-business-model-is-a-failure.html

Igor Faletski, https://hbr.org/2013/01/yes-you-can-make-money-with-op (Article I found for this week’s readings)

==========

I don't recall if I've mentioned this in my previous blog posts, but I really appreciate these weekly readings on the different aspects of open-source, especially this week. I think it's so easy to just get caught up in the actual work I'm doing with Cesium and forget that there's more than just writing code that goes into a successful open-source project. For example, before this week's readings, I never realized that open-source projects would have to consider choosing a business model. It seemed like so long as an open-source project maintained its group of motivated and innovative developers (as was mentioned in the readings about the motivations of FOSS about a month ago), the project could continue to develop and flourish. But Meier's article brings a good point in that it's not necessarily the quality or quantity of developers involved in the project, but a matter of whether a project has the resources (or funds to buy resources) that are used to maintain the project itself. It makes sense at that point, then, to have to decide whether you will leave your project to someone who can provide the necessary resources or explore business models to generate the funds needed for said resources. Though Meier's article offers what he considers to be successful business models for open source projects and Rubens insists on the failure of the open source business model, the authors' definitions of success differ from each other. Meier makes it clear that success is defined by the developers themselves; success can be defined by the number of employees, number of paying customers, number of times the project has been forked by other companies, etc. Rubens, though, argues that the success of an open-source project is determined by revenue it generates. It's hard to, then, to compare and contrast the authors' arguments given that their arguing for different things; Rubens actually concludes in his article that open-source projects have a chance of success if they create SaaS alternatives, which is one of the successful business models Meier includes in his article. I do think that Rubens makes some convincing points in regards to the failure of the open-source business model; one of the more interesting ones is the fact that proprietary software companies have a bigger budget for marketing efforts, and while they are costly, they are definitely effective. A smaller open-source company might have a good product, but if a bigger company is better at convincing customers to use their similar product, then the bigger company wins those clients. Given that Rubens article was written a couple years ago, it would be interesting to see if there numbers to support/debunk his predictions on the rise of cloud-based/SaaS offerings of open-source projects. In regards to the article I found about how a company can make money using FOSS - what I appreciate about this article is that it gives more real-world examples besides RedHat. WordPress, for example, is a software that I didn't know was open-source, but given its popularity it seems like it made good decisions when choosing its business model (more specifically, in choosing which of its products it would offer for a fee). From the "success stories" that are described in this article, it seems as if the successful ones were able to find a balance between maintaining open source technologies and incorporation paid solutions.

[tmblrofji-blog]

Readings 3/20

Links to Readings:

(Walli) : https://opensource.com/law/13/1/which-open-source-software-license-should-i-use

(Wilson) : http://oss-watch.ac.uk/resources/fossandpatents

Though I could see how the information about open source licensing offered in these articles could be important for those who want to license their projects, it was initially difficult for me to gain anything insightful from this week's readings. I am someone who is working on an existing open-source project without any intentions of using the software in any way other than to improve on the existing code and implementing new features where needed (i.e. my current PR to implement distance() function). I don't have intentions to take all of the source code of Cesium, make my own project using that code, and claim it all to be my own. But then I looked up which license Cesium uses (Apache 2.0), and according to the Walli's article, this is one that has no copyleft requirements - such a license allows "anyone to use the software in anyway without requiring much more than maintaining copyrights", so it is somewhat helpful to know that if I were to modify the code and redistribute it, I could do so rather freely so long as I follow the guidelines regarding the copyrights. I also noticed that Cesium uses other third-party open source software and includes their license information as well; for example, Cesium uses Tween.js, a tweening machine for easy Javascript animations, and its license allows any person to "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software," so long as they include the copyright notice. I hadn't thought that merging other open source software into your own project as another way of "modifying" the code as it's understood in open source; I thought modifying meant actually changing the source code and developing something new from those changes. This insight helps me to better understand the significance of open source licenses; depending on where it falls on the "copyleft" spectrum, there is virtually nothing that stops a developer from using open source software in their own projects however they wish so long as they give credit where it's due. I also found it interesting in Walli's article that he does not include some sort of visual aid like a table or decision tree because of the many edge cases and nuances that would affect what kind of license a developer seeks. Wilson also seems to suggest that it's difficult to characterize licenses as being strictly in one camp versus another; rather licenses fall within a gradient running from 'strong copyleft' to 'weak copyleft'. If there are so many nuances and details to consider when choosing an license, than these two articles, in my opinion, are hardly enough for a developer to make a decision; Walli's article might be a good starting point, as it groups licenses together based on certain characteristics, but I would imagine that it is not a comprehensive guide to all the possible licenses given that a software may have many more needs to be considered. This makes me wonder whether there is actually a guide published by the Open Source Initiative or another group that actually outlines all the different licenses and which one would best suit the project in question. 

Link to a "current events" reading I found on open source licensing: https://techcrunch.com/2017/02/23/fossa-scores-2-2-m-seed-round-to-automate-open-source-license-management-for-developers/

[tmblrofji-blog]

Update 3/20

And we’re live after a week of rest that is Spring Break :) By the end of last week’s meeting, I had made a pull request with my implementation of distance, but my tests failed. So my task was to try to finish a correct implementation of distance. 

Issue: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865)

Pull request: https://github.com/AnalyticalGraphicsInc/cesium/pull/5040

What did you accomplish this week? Per Sean’s suggestion, I set distance to point to a local function, which I implemented and included as well. Then I included if/else statements in the getEvaluateBinaryFunction (similar to getEvaluateUnaryFunction) so that if the call was distance, it should check whether the inputs match (i.e. both inputs are numbers, vec2, vec3, etc.) and then call Cartesian2/Cartesian3/Cartesian4.distance on the given inputs. It should also throw an error if the inputs don’t match. My tests for distance did not change.

Approximately how many hours did you spend working on your project? About 1 hour to write the changes that Sean suggestion to distance(), but about 4 hours trying to make the new branch off of 3d-tiles/figure out why WebStorm wouldn’t recognize the new branch I made/unsuccessfully trying to resolve the problem of Git not recognizing the changes I’ve made to Expression and ExpressionSpec.

If you didn’t accomplish everything you intended, why not? Last week when I made my first pull request, I kept running into issues with actually pushing my changes to the PR. I figured out a work-around, but Sean reminded me that I should make a branch off of the 3d-tiles branch and work on that. I did so (while running into trouble syncing up my new branch with WebStorm), but when I actually made the changes to distance as described above, Git doesn’t recognize my changes - it keeps saying that my branch is up to date with the origin/3d-tiles branch. I made sure that my local branch is keeping track of changes compared to the remote branch. I have a feeling this has something to do with the problems I had last week, so I wasn’t able to push my changes to the PR and am planning to bring this up to tomorrow’s meeting/see if Dylan can help me figure out the problem. In order to show that I did do the work I described above, I’ll be emailing Dylan with screenshots of my changes.

What are you planning on doing in the coming week? I want to make sure that distance works and run it by Sean (i.e. check if there’s anything I should change in terms of style, etc.). If it does, then I will want to talk to him about the other functions like length, dot, and cross - they will probably also need special if/else statements like the ones I added to getEvaluateBinaryFunction, which makes me wonder if there’s a better way to structure that/whether I should be refactoring those if/else statements as a separate method? I also want to check whether my work would overlap with anything that Jane is working on, since I remember that she mentioned refactoring some of these functions as well.

What might get in your way of doing it? If distance still doesn’t work :( 

[tmblrofji-blog]

Update 2/27

At the end of last week's meeting with the TA, we decided it would be best if we gave Jane the responsibilities of finishing up other binary functions like atan2, and instead have me work on including vector styling support of the functions length and distance. (Link to issue here: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865)

What did you accomplish this week? This week I included the function distance in Expression.js and wrote unit tests for them in ExpressionSpec.js. It took me a while to understand how that works - last Monday, after Dylan walked me through several other pieces of code that included mathematical functions that could help me, he advised that I write a question in the issue about whether there were any functions in Cesium that could help me include length and distance into the vector styling language. Sean responded, and pointed me to try using Cartesian3.length and Cartesian3.distance. I found that Cartesian3.length didn't exist but (belatedly found Cartesian3.magnitude), so I tried to work on distance instead. 

If you didn't accomplish everything you intended, why not? I didn't get to actually test whether the code I wrote works with the unit tests. The way I originally attempted to include distance (distance : Cartesian3.distance()) didn't work when I first tried it because WebStorm was giving me syntax errors. After trying several other ways, I emailed Dylan for advice, and said that the original way I tried should probably work. So I've included it in my code again, but have yet to try running it because I ran into problems on making a new pull requests with these changes (I try to push the changes to my fork, but I keep getting Permission Denied errors). I will make edits to this post once I figure out these pull request error/pushing errors. Approximately how many hours did you spend working on your project? I spent approximately 3 hours looking into the functions that Dylan and Sean pointed to and writing implementations with those functions, and 2 more hours writing tests.

What are you planning on doing in the coming week? I want to make sure that distance works, and if it does, move on to working on length. I also want to resolve the Permission Denied errors I get with Github so that I can include my changes in a new pull request.

What might get in your way of doing it? If the way I was trying to include distance is completely wrong, then I'll need to start over and ask for more help.

2/27/2017 12:05AM Notice: I'm working on trying to make a pull request so everyone can see the changes I made/code I wrote; if it doesn't get resolved before the meeting tomorrow, I will upload screenshots so you can at least see what I've done.

[tmblrofji-blog]

Readings 2/27

Readings: 

http://l3d.cs.colorado.edu/~yunwen/papers/ICSE03.pdf·     

http://www.diss.fu-berlin.de/docs/servlets/MCRFileNodeServlet/FUDOCS_derivate_000000000137/discpaper19_04.pdf

It didn't occur to me, until I went through this week readings, that the motivation of open source developers would garner such interest to the point where it'd become the topic of various scientific research papers. But now that I think about it, open source is an interesting phenomenon - huge communities of developers are investing time and effort into building software without receiving certain benefits (like an annual salary) that they would otherwise get at a software engineering job that'd require the same kind of effort. And like the Bitzer paper mentions, "economics would predict that privately provided public goods [such as open source software] suffer from problems of under-provision, delays in supply, and inferior quality" (2). But the fact that the development of open source software flourishes and sometimes even more so than commercial software, is worth investigating. I believe that the Ye & Kishida paper highlighted a lot of key factors that seem to contribute to the motivation behind open source developers. In my opinion, role transformation is one of the strongest reasons mentioned in this paper - regardless of what level a new developer may be when they first join a open source project, there is always a variety of tasks that they can tackle right away. The fact that roles are not fixed, but are open for growth, allows for developers to grow in their technical skills and quality of contributions as they continue to invest time and effort into the project. I think equally as important is the evolution of the tasks themselves, which was subtly mentioned in this paper. There needs to be an increasingly level of difficulty in the tasks/issues themselves for the developers to continue to be challenged and grow. A motivation that this paper mention that I struggle to agree with is the need for positive reinforcement. This paper argues that altruism isn't enough; there needs to be some sort of recognition for the developers' contributions for them to gain a satisfaction in their involvement in the project. This differs from the Bitzer paper in that the programmer needs to feel that they've given a gift to the community. I mentioned in a previous post how it seems as though programmers who are already working full-time/don't need to use open source as a way to demonstrate their technically skills to future employers like students do seem to participate with more altruistic intentions, but I would think that positive reinforcement and rewards for contributions would be much stronger motivations for those involved with open source. However, in my own experience with CesiumJS, I haven't actually seen anything in particular where certain contributors are recognized, yet there seems to be consistent activity and contributions to the project. From what I've seen so far in practice, the level and quality of contributions are not affected by the presence or lack of rewards, though this could be different in other open source projects that I don't know about.

Another article I found about what motivates people to contribute to FOSS: 

https://ai2-s2-pdfs.s3.amazonaws.com/953d/9faa84cca23a9f3bc07d23eaba83acdb25fa.pdf

[tmblrofji-blog]

FOSS Update 2/20

What did you accomplish this week? This hasn't exactly been the best start to my work with Cesium - in short, I did not accomplish any of my assigned tasks this week. I had been asked to implement the binary function of arctangent, known as atan2 (Issue here: https://github.com/AnalyticalGraphicsInc/cesium/issues/4865). This also required writing test cases and documentation.

If you didn't accomplish everything you intended, why not? To be completely honest, the main reason why I didn't get to accomplish what was assigned was because I underestimated the time it would take me to understand the project and relevant source code. When I was first assigned to work on the arctangent, I thought that this would be a relatively easy issue to solve (and maybe it truly is that easy). The TA had mentioned that I could look at his previous pull requests since he worked on implementing the unary functions, and pointed out that there are built-in math functions with Cesium that could potentially help me. It seemed as if I had a lot of resources and that implementing a math function would be pretty straight-forward. So I estimated it wouldn't take me more than 8 hours to finish everything and decided to set aside that much time during the weekend. But all that time was spent mostly trying to undestand the code, which I foolishly overlooked given that I've never formally learned JavaScript. I struggled to understand what kind of data structure we were trying to find the arctangent of (is it a vector as it is understood in mathematics, or is it a different kind that is special to Cesium?) and how the other unary functions had been implemented, since it didn't seem clear from the source code how that was being done. Had I realized that amount of time I would need to undestand everything, I would have done so much sooner so that I could ask questions accordingly and try to figure out how to fix my first issue. The reading for this week also hit close to home; I wish I had recognized sooner that like the author, I would need a significant amount of time to understand what's going on in the project to make valuable contributions to the project.

Approximately how many hours did you spend working on your project? I spent 8 hours trying to understand the code, reading documentation, and looking up tutorials on JavaScript.

What are you planning on doing in the coming week? I’m definitely planning on finishing the tasks that I didn't even get to start this past week. I also plan on asking the TA for clarification on what's expected of me in terms of this issue - it seems as if there already is atan2 in the source code, which I thought I was supposed to implement. Maybe it's just that I don’t understand how the code work, in which case I plan to ask the TA for help (or at least pointers on how I can try to understand the code on my own) in that as well so I can really get to working on this issue.

What might get in your way of doing it? Hopefully I won't make the same mistake of leaving the issue until later in the week/exercising poor time management, since that seems to have been the biggest reason why I didn't get to finish my tasks on time.

[tmblrofji-blog]

Readings 2/20

Reading for this week: http://words.steveklabnik.com/how-to-be-an-open-source-gardener I find that Klabnik was incredibly smart in the way he made his open source contributions, and I sincerely wish I read this article sooner so that I could have taken a similar approach in my previous (and current) attempts to start working with open source projects. It doesn't say that the work he describes in this article were his very first contributions to open source in general (and I would guess that they weren't), but this article could very well be tailored for beginners in open-source given all of the benefits they'd experience if they took a similar approach as Klabnik. Having to sift through 800 issues would not have been an exhilarating experience by any means. But through that, Klabnik not only helped clear out a good number of issues, but he also built a solid understanding of the project but learning about common questions, comments, and problems, and about virtually every bug that needed attention. Though his aim is to highlight contributions that don't involve coding, the knowledge he gained from such contributions would have (ironically) equipped him to be a valuable contributor code-wise; he knew what kind of bugs were available and could choose the ones he felt confident in writing a patch for, and would have known how the bug he was trying to fix could possibly be related to other dependent bugs, and possibly how other features in the project would be affected by his patches. I wish I had read this article earlier - last year, I tried to get involved in an open-source project in order to improve my programming skills, and found one that interested me (https://github.com/churchio/onebody), but I had no idea where to start or what to work on. I was also incredibly intimidated by the idea of trying to contribute code when I only had 3 months of programming experience under my belt. Had I approached this project in a similar manner as Klabnik, I would have had a better understanding of the issues that were at hand, and would have probably formed more ideas of how I could contribute (whether that be through coding, working on documentation, etc.). I also wish I had known that contributions to open source don't necessarily have to be coding (since that's definitely the notion I had even up to a couple weeks ago), and had tried out some of the suggestions that are mentioned in the article I found on how to make non-programming contributions to open source (linked below). I also wish I had read this article at the start of what has been a painfully unproductive week in terms of my contributions to Cesium - but more on that in my Updates post for this week.

An article about ways in which people can contribute to open source other than “writing code”: https://opensource.com/life/13/10/contribute-open-source-project-no-code Bonus: Another article I found that doesn’t exactly related to the type of article we were supposed to find this week, but one that I wanted to keep a reference to! https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.5qcpn6qhf

[tmblrofji-blog]

2/13 Update

At our meeting last week, I set up my environment so that I could start contributing to Cesium. This involved forking the Cesium repo, downloading Node.js and building the Cesium code. I also downloaded WebStormJS at Sean’s suggestion so that I have a JavaScript IDE to work on throughout the semester.

Sean also had us fix a couple of minor issues so that we could try merging pull requests, but since I did not have a Contributor License Agreement submitted at the time of the meeting, we could not confirm this until the end of our meeting. I also was not assigned to work on any issues this week other than to add myself to the Contributors.MD.