Workshop on Software Architecture for Agile Development
This blog was found from this site. Hayim Makabee, the blogger did a workshop software architect for agile development. At the workshop he did a presentation on Adaptable Design Up Front in an agile project. He explained how much adaptability should be done on a project. The topic was explained with different software architect with different software programs developed over the years. There were also exercises that further explained the definition and the evolution of different design systems. The blogger included pictures and the slideshow from the presentation. I quickly went through the presentation. The first slide after the title slide shows where he worked over the years. Some of the companies he’s worked for includes IBM, Yahoo and many more. Part one of the presentation was on Architecture and agile. In this part he explains the different approaches in the context of agile, the approach of Adaptable Design Up Front, guideline on how to use it in practice and examples of it in the real world. Part two was about manifesto for adaptability. This included lean startup, minimum viable product, manifesto for adaptable software development, SOA principles and micro service practices.
This was a short blog to read. Luckily there was a slideshow to look at. This was again interesting to read. As I went through the slides I noticed he included a design pattern for part one of the presentation. I gave a brief summary of the slideshow and mentions the topics that the blogger talks about. The slideshow goes through it with more detail and explains everything mentioned in the topic. The slideshow also includes many pictures and examples used for the real world. Everything explained in the slideshow had pictures or diagrams making it easy to understand. The pictures from the workshop show the group working on an activity. The activity ha the audience create a taxi ordering app with design patterns. This activity helped explain the definition and evolution of design of a software. This blog showed me how useful design patterns and software design can be used in the real world. From the picture the group looks like they are learning from the slideshow and enjoyed the worksop overall. I would have found the workshop interesting if was there. His list of job credentials at the beginning of the slideshow sort of gave me an idea of where to look for a job in the future.
This blog is on the topic of art of software development. The author believes the software development is like art. He also explains why it matters. Teaching someone about software development with the concepts and technique of programming is similar to teaching someone about art. Both difficult and challenging. The final product depends on the student and mentor. The author compares telling a programer how to write a program to someone telling Van Gough how paint his masterpieces. Both end with negative results. Similar the final product of an artwork depends on the student and mentor’s insight. The author briefly gives us the definition from engineering and art both which come from Wikipedia. Engineering is “the application of scientific, economic, social and practical knowledge in order o build, invent, maintain, research, and improve structure, machines, devices systems, material and process.” Art is “a diverse range of human activities and the products of those actives usually involving imagination or technical skill.” He then states software development comes from the imagination and technology of humans. Software developers can choose the founding blocks for their programs to make it run. The author concludes that yes software development is in a way a form of art and engineering. Like artists, developers need the freedom to choose how to code and write the program. They can write a program for a client within a certain parameter, but still need the freedom to do it how they want to. Give the programmer too much of a restriction on the program and they won’t have enough freedom or space to create the program and make it run properly. The author does not fully explain on why it matter, he gives his opinion on what he thinks then leaves the question open ended for reader to decide for themselves.
Again, I liked this blog. I agree with the author of software development being a mix of both art and engineering. You need a creative mind to create a program but you also the technical skills to know how to run the program. Again this gives me an idea of how developers work and what they can do. I have always seen programming as a type of art. My parents have told me I’m artistic with technology and learning how to write programs. I have always been able to figure out how technology works, and figure out how to fix them if theres is a problem.
This blog talks about how the concept of “Art of War” applies in the world of software development. He starts with explaining the history of “Art of War”. The idea dates back to fifth century B.C., by an Ancient Chinese military strategist named Sun Tzu. The text from the book is divided into 13 chapters, and still used in military schools in the East, and is suggested reading for the west. The concepts of “Art of war” have not only applied in the military at war but as well as in politics, sports and software development. This blog goes through certain chapters and section of the book, and explains how it is used in software development. The first section comes from Chapter 2. The idea is teamwork. If everyone on the team is working on a program and they have no goal or no deadline for the project, then the people become frustrated and the effort in the project declines. The next part from chapter two is about timing. This one states, the faster you can get a program running and turn it in with out bugs, the quicker you’ll get feedback from the client. Chapter three is based on leadership. With a team of programmers one on a program there needs to be a leader to make sure everything is running smoothly and going the way it should. Chapter six talks about repetition. Using one method for one project might work well, so you’ll try the next project with the same method as the previous one. That might not be such a good idea. Instead, learning how to write in different coding language, and different methods will help you become a better programmer and help the program run better itself. The next sections talk about constantly improving to make things better. In programming, programmers are constantly fixing bus to their programs to keep it running smoothly. The next section again talks about teamwork, how everyone on the team has to work to the team has to work together on the project and not one member alone can do everything by himself. Again with teamwork, talk about making changes to the program with other members, instead of doing them yourself without anyone knowing. The next section talks about motivation, to keep the team going and help make the program get finished faster. The next section states if a piece of code looks bad, but work fine don’t change it or destroy it, just leave it alone and let it be. The last section talks about anti- patterns. Which means do as told and don’t stray to try to change things to make it netter because it might not work out in the long run. The author concludes that though these idea were first used for warfare the idea of teamwork, efficient and time can apply to software development as well.
Again, another good blog. I like the talk about teamwork for programming. Again this shows teamwork and the importance of it when working on a project. Which occurs in any job field with programming.
This week I read on why writing a software design document matters. This blog goes through the steps of what is needed in a design document. The program idea could start with a call or Skype meeting between the programmer and the client, with the client telling the programmer what he wants in the programmer. The programmer is then left to create the program once and outline is created, and meets up with the client one last time when the program is finished to make sure it is what he wants. Chris Fox, the author of the blog entry, goes through each of the steps with a brief summary and a picture or diagram of what each of the steps would look like. The specification of a software design document show that the design goal of the project is going to be. This is created by the developer and the client on what is needed to be done and how the program or in this case application should work. The interface is the framework of the application. This is also the most problematic trying to get it to look perfect to what the client wants. Functionality how the application works and what it is supposed to do. Milestone, what the application is supposed to do once finish. The blog also gives examples of outlines for the document which features all of the steps. The outline should include the goals of the program, the function of the program, the users’ interface, and its milestone. The author’s example of a UI description that he used was for an app used on an iPhone. The description included a navigation bar that controlled the app and where to go to different locations of the app, and a table of a layout of what will appear on the screen of the phone, including images and texts. Steps may change overtime as the application is being designed and programmed. The author gives us these steps and what to do as an example of a free lancer with one client.
This was another interesting blog. This blog showed another reason why we need a design map or outline for any programming. The diagrams show how the steps for the outline works, whether it is written on paper or typed up on the computer, both show the outline for the program and how it is expected to run for the user. Not only does this design work for programming site, it also works with programming applications. This shows that you need a design outline or diagram before creating any kind of program. This blog gives another method for designing a program. I would probably create an outline of what the program needs to do and how it should run, create a UML diagram for it then try to create the program itself.
This is another video from Joel Spolsky. I found this video through the last blog entry from last week. In this video he talks about the impact of coding in everyday life. He uses a taxi as an example of how coders deal with coding. he mentions if the person tries to make the taxi turn right, instead of the taxi turning right, it might have the trunk pop open or the taxi turn in the opposite direction. The driver will ask what’s wrong and try to figure out the problem. The driver will go online and find another driver had the same problem asked the question then was given the answer. The driver could use the answer to solve his problem. Before stack overflow, there was a site online where programmers post questions to a coding issue, then would have to pay the company money to see their own answers that they have written up, Stack overflow was created where programmers can write questions to the program they have a problem on and other programmers can answer. Those answers are rated by other programmers who use the site. Those ratings can help a programmer build their reputation as a programmer. This could possible lead to jobs as a programmer in the future. Programmers need every detail of instruction for the program to run properly. Like mentioned before, algorithms are used in software design to run programs on websites. These algorithms allow a site to post certain pictures, articles and other posts, based on what the user is searching for or their feelings towards a certain topic or event.
The video was interesting. Joel uses everyday trends such as Uber and Facebook to explain how coding works in general and how it is used in everyday life now. I picked this video because I really liked the last video, and video was similar to the last one. The last video talked about programming and coding effecting the future of people. This video talked about coding impacting everyday life of today. This gave me a better idea of how a website work and how a program runs. Again this shows me what expect in the workforce of a programmer. Joel compared the early days of programmers working similar to working at an assembly line. Programmers were hired to create a program write it and run it, and doing it in small cubicles with computers that did not work properly. Now a days programmers work with he company on the spot to make sure the program runs properly and fix and problem as they arise. This gave me a better understanding on how algorithms work on a site and how to use them for when I create a site and run it.