During this last sprint I spent my time working on two things, that of continuing to try to get the styles to work for the buttons on our program and our teams final presentation. In continuing with the styles of the buttons from the bottom navigation bar, I finally tried to create and apply a palette. Ignite UI uses a thing called palettes which is a built in feature that takes two colors as primary and secondary, as well as a few other built in color groups, to create a large “palette” of colors that you can reference. To do this you create an SCSS file, short for Sassy CSS, which is a super set of CSS allowing the programmer to create variables, nested rules, functions, etc.. When you create this SCSS file, you have to import the Ignite UI style index, as well as provide the primary and secondary colors. From here you can define a custom gray scale palette, or take the one automatically created which has a default color of black. Finally once the palettes have been set, this is where the SCSS comes in, by allowing you to create color variables which can be used over and over. To create these variables Ignite UI provides a function for creating these colors, with 3 inputs; palette, color, and variant. The palette is one that you have created, the color is one of the 8 available through Ignite UI, and then finally a number for the variant with the default being 500, lighter shades being 50-400, and darker shades from 600-900. An example of one of these color variables would be “$my-primary-600: igx-color($my-palette, ‘primary’, 600);” I did all of this trying to hopefully change the styles of the individual button elements of the bottom navigation bar, but instead it would apply to most or all of the document. Although I did not get what I had wanted working, I feel that I did learn a lot of the way that this Ignite UI worked during this sprint, having spent many hours trying several different possible solutions. I feel with more time I would have been able to figure out this problem but my team also had to start planning and creating our final presentation for the class. For this my portion of the presentation was to be on the Ignite UI as well as some of the style stuff involving SCSS. To help me with this I spent a long time reviewing the Ignite UI website which was very expansive and almost like a Wiki. On thing that was very helpful with there website was the inclusion of examples using Stack Blitz, which gave examples of how the code would be run, and which could also be changed. This sort of program example helped a lot in trying to understand how a certain element they have in the Ignite UI worked when compiled into code, and I would highly recommend a version of it being used in future classes.
An algorithm is a set of rules to be followed in order to solve mathematical problems in numerous steps that usually involve repetition of an operation. Sometimes algorithm problems do not show up at the beginning of a project. As Steven S. Skiena states, different programmers find them out as subproblems, which appear to be … Continue reading Read Constantly
We live in a world where different complex software projects have different deadlines and they use a variety of tools to finish the projects. Most of the time employers cannot afford to hire too many specialists to fill every role. You learn only enough about any tool to get today’s job done. You select some … Continue reading Dig Deeper
On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my tenth and final individual Apprenticeship pattern I decided to blog about “Craft Over Art” pattern.
The pattern “Craft over Art” is the idea of choosing the craft of programming and making thing functional. Rather than choosing art of programming and making the program look beautiful but not so functional for the customer. Even though you may find an opportunity taking your customer problem and making something nice that will impress your coworkers, it is best that you put the customer needs before your own selfish wants or needs. When it comes to dealing with customer your goal should always be choosing creating a functional valuable product, rather than something else that only advance your own self interest. When dealing with customers it is more important to choose the craft of software development rather than feeding that desire to creating something beautiful, yet not truly functional or deliverable in the real world. This pattern is not telling you that things can’t be beautiful it more saying that whatever you build for your customer must be functional and useful, therefore you must be willing to sacrifice beauty over utility. “The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility.”
This pattern helps you understand the impotence of building “Craft over Art” because it reminds you that creating something useless yet beautiful is not craftsmanship. I agree with this idea because crating a useful software program far more important than a beautiful non-functional one. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that I should always be willing to sacrifice beauty before sacrificing usefulness.
Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.
From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.
According to my next Apprenticeship Pattern blog I chose “Draw Your Own Map,” as one of the most interesting patterns and which fits perfectly in my logic. When you decide to enter the Software Development world, you may think that it’s a hard and tough game, or sometimes you believe that your career will always … Continue reading Draw Your Own Map
Hello, again fellow readers!
Today we will once again be continuing our journey into software apprenticeship patterns. From last week, we will continue on to the next pattern, Expose Your Ignorance.
This pattern is all about once you have gotten yourself onto a team where you can learn more from your fellow teammates, presumably in a job. The problem is that well… you are ignorant. You need to deliver and you have a lack of knowledge in whatever language or technology you need to be able to deliver.
The offered solution is fairly simple, ask questions and don’t be afraid to show that you are ignorant in a particular subject. You should recognize that it is human to want to appear competent and not appearing competent is not a bad thing. It is all part of the learning process. As a software craftsman, you need to know many different subjects and technologies. The pattern suggests that people who are uncomfortable with the learning process of appearing ignorant become experts instead. They seek out expertise in one particular field and never venture too far from it. Experts are important but the journey of a software craftsman is much longer and requires a broader scope of knowledge. You become an expert in one or several subjects along the way but that is not the ultimate goal. For a software craftsman, one of the most important skills is the ability to learn. To solve this problem the pattern suggests writing down a small list of thing you don’t really understand about your work and posting it in public view.
This pattern I find interesting. What I found most interesting was the distinction made between the software craftsman and the expert. The pattern admits that a software craftsman will likely become an expert in a few subjects but that is not the ultimate goal. The goal is not explained in the pattern (I’m sure it is explained at the beginning but I have forgotten it at time of writing) but the difference between the expert and the craftsman is that the expertise is not the goal. A craftsman goes further than becoming an expert and goes on to craft with the expertise of many under his belt where the expert gains expertise and then rests on his laurels. I do also appreciate the part where it states that by admitting ignorance it will increase your reputation greater than “fake it until you make it” will.
That’s it, for now, my fellow readers. Until next time!
Hello, again my fellow readers!
This week we shall continue looking at Apprenticeship Patterns. I decided to skip over the Unleash Your Enthusiasm pattern and instead decided to talk about the Concrete Skills pattern this week instead.
The Concrete Skills pattern seeks to solve the problem of joining a team of craftsmen to further your learning opportunities. This could also be the all-important problem of getting a job. The problem keeps on going as you are too much of a risk as you may not be able to directly contribute anything to the team. You may not be able to even indirectly contribute.
The solution proposed is fairly self-explanatory. It’s right in the name of the pattern! Acquire concrete skills that allow you to demonstrate ability with relevant tools and technology. The pattern does suggest acquiring some skills that are geared more towards getting past HR and managers. I do like the proposed idea of “buzzword bingo” that the pattern mentions briefly. The rest of the concrete skills that you learn should be directed at showing your team that you are actually useful and that someone doesn’t need to look over your shoulder constantly to ensure you don’t mess up or break something. It goes on to make a good point. When faced with a hiring manager, they will ultimately be looking for someone who can actually contribute in some way on the first day. Having concrete skills is, as the pattern puts it, a way to meet them halfway. Then as you progress, you will have to rely on these concrete skills less and less. To learn what concrete skills to build, the pattern suggests looking at resumes of people whose skill you respect in the business. Identify some skills from the resume and work on them and of course, keep reviewing your own resume.
This is what drew me to talk about this pattern. It is directly relatable to me as I am in the job hunt as I am graduating soon. I found this entire pattern to be generally good advice for anyone in the software development field seeking a job. It also corroborates what a lot of people have given me advice for job hunting.
That’s all for this week. I wonder what pattern I will get to read about next?
Until next time readers!
Hello, again my fellow readers!
Last week we took a look at the beginner pattern, Your First Language. This week we will continue along the path to the next pattern, The White Belt.
I understand where this pattern is coming from. I do get that an open mind can, and most likely will, lead to new possibilities. I agree with that. I suppose that my issue is that forgetting to accelerate learning is still something I find a bit backward. Looking at it, I must admit that I have not tried this method. Typically I find that making associations to things you do know is a good memory tactic and can speed up learning. It is entirely possible that the White Belt pattern will work for me. The only thing for it is to try it. I can legitimately say it doesn’t work without trying it for myself now can I?
Looks like I have some unlearning to do in my future.
Until next time readers!
Good my fellow readers!
Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?
The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.
I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.
That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!
This is the last blog post for Individual Apprenticeship Patterns, I want to end with “Record What You Learn”. Most of what we were talking about was learning and how to apply it to the real world. I thought this is important because I am also doing this in daily basic. I keep making same mistake, and I learn to avoid it slowly. There are issue I just need to more practice to avoid, but there are mistakes I could have learnt. The book suggests that some platform to write down. Ade uses two instances of the same wiki, one for his private thoughts and the other for stuff he wants to share with the world. That is the good idea, some from my mistakes I didn’t want lets other to know about it. But after this book I wouldn’t mind others to check on my mistakes. They could help me to fix it or at least I will learn from it.
By said that, I also want to connect this to the next pattern “Share What You Learn”. Like I mention above, we could become a journeyman, the ability to communicate effectively and bring other people up to speed quickly. We learn what need to be share and what shouldn’t. It does not matter what you take note for yourself. Before share to others, you need to think if that will have negative effect to them or even to the team. This could damage the relationship of the group. They also suggest that shared as blogpost about the lesson which is soft of what we are already been doing. In blogpost we also could share our solution and have conversation with other.
This is my final thought of the book. I think this book is good on the guideline on the ethics side of the industry. I also have honest advice from experience people. They gave short good example/advice that easy to ready. I am will read the rest of the patterns and keep this book with me.