tag:blogger.com,1999:blog-78275673959777229052024-03-14T01:17:49.389-05:00Christian PetersTDD DEVChristianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.comBlogger54125tag:blogger.com,1999:blog-7827567395977722905.post-32626761695878852812019-09-08T13:52:00.003-05:002019-09-08T13:52:57.514-05:00Are you running a SOLID Meeting?Teams can spend a lot of time in meetings. Most meetings are held with good intentions and can lead to the desired outcome. However, I think most people would agree that they spend more time in meetings than they would like. I believe that the main reason for this is that too often a meeting is scheduled without having a clear plan or goal for the meeting.<br />
<br />
The thinking seems to be that there is a problem that needs to be addressed so if we gather everyone together we can figure it out. Teams work to plan and organize their work before actually starting the work, so why would we think that putting together a meeting without preparing for it would lead to positive outcomes?<br />
<br />
I think that a little work before a meeting is scheduled could go a long way to make meetings more engaging and leave the attendees feeling like it was worth their time.<br />
<br />
<h3>
Introducing the SOLID meeting</h3>
Developers use a mnemonic, <a href="https://en.wikipedia.org/wiki/SOLID" target="_blank">SOLID</a>, for describing how to structure good code.<br />
<br />
Using these same letters with different meanings I think we can use SOLID as a template to plan a good meeting.<br />
<br />
<b><span style="font-size: large;">S</span></b>ingle Focus<br />
<b><span style="font-size: large;">O</span></b>n-Time<br />
<b><span style="font-size: large;">L</span></b>ist your Agenda<br />
<b><span style="font-size: large;">I</span></b>nvolve Everyone<br />
<b><span style="font-size: large;">D</span></b>ecide or Deadline<br />
<br />
<br />
<b><span style="font-size: large;">S</span></b> for Single focus. Often meetings take on more than 1 focus because the team is together so might as well cover as much as possible. The problem is this doesn't allow for a clear end to one discussion and conversations can find their way off track returning to earlier topics. My suggestion is that if you need to cover more than 1 topic, make it more than 1 meeting. Complete your first meeting on the first topic and then take a break. Allow people to reset, 5 or 10 minutes, and then start on the next topic treating it as its own complete meeting.<br />
<br />
<b><span style="font-size: large;">O</span></b> for On-Time. Start and stop your meetings at the time they are scheduled for. Let everyone know that your intention is to start on time and hold to your plan. To be able to end on time, you will likely need to plan for some buffer time. If you expect your meeting to take a full 60 minutes, you are likely not going to be able to cover everything in a 60-minute meeting. Instead, plan for 45 minutes and either tighten your schedule or cut out steps. If you find your team unable to start on time waiting on another group to leave a conference room, book the room earlier than you plan to start the meeting to give them time to clear out.<br />
<br />
<b><span style="font-size: large;">L</span></b> for List your Agenda. How can you keep to a schedule without first creating an agenda and estimating how much time each part will take? Creating an Agenda helps in multiple areas. First, you should share the agenda at the start of your meeting. Everyone now knows what to expect and will probably even help you stay on target. Attendees will be less likely to try to jump ahead and if they do you can remind them when they will get their chance to talk about that.<br />
<br />
Just getting everyone in the same room and discussing something for an hour is not good enough, you need to have at least a rough timeline. The more meetings you facilitate with your team, the easier it will be to know how much time to give each step. You can also use the agenda to help steer conversations back on topic and guarantee you accomplish your meeting's goal. Ask yourself if someone else could successfully run the meeting if you were to give them your agenda.<br />
<br />
<b><span style="font-size: large;">I</span></b> for Involve Everyone. Having one or two people dominate a meeting is a great way to have people check out and not care about your meeting. Start by being mindful of who is invited to a meeting, does everyone really need to be there? If someone isn't going to be participating why would they need to be a part of the meeting?<br />
<br />
Next, make sure you give time and opportunity for everyone to be heard. One of the best ways to accomplish this is to have everyone write down their thoughts and ideas by themselves or in small groups before sharing with the larger group. This approach ensures everyone gets to be involved and will help them stay engaged throughout the meeting.<br />
<br />
<b><span style="font-size: large;">D</span></b> for Decide or Deadline. Leaving a meeting without any sense of accomplishment will make your attendees feel like it was a waste of time. Your meeting should end by either coming to a decision or making a plan for what needs to happen next. Before ending the meeting reiterate what the outcome of the meeting was to give a summarised memory of the meeting.<br />
<br />
When trying to reach a decision, you should try to involve everyone. Have everyone vote on the options in secret and then share their vote. This prevents people from being influenced by others and allows everyone the opportunity to share. If everyone comes to a consensus, congratulations you are done and can move on.<br />
<br />
If you have a majority in favor of one option, you should probably choose that option and try it out. Spending time trying to get to a consensus can wear people down. Plan to move forward with the majority option and share back how well it goes. Worst case, you are learning about the chosen option and that informs future decisions. Best case, you have a working solution without spending any additional time in meetings.<br />
<br />
The last option to end a meeting will be to create a deadline for the next steps. This means you should plan a future meeting on your topic while you are still in the current meeting. This gives your attendees time to research, think about, or experiment with options and a deadline to do it within. It could also lead to majority decision being made once people realize they are going to have another meeting on this topic.<br />
<br />
<br />
Try using these ideas when planning your next meeting and see what kind of feedback you get from your team.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-37920814899179441762018-02-20T08:03:00.000-06:002018-02-20T08:03:52.319-06:00Design Pattern: Unit of WorkThe Unit of Work pattern defines an approach to create logical transactions within a system that might otherwise not be transaction based. It commonly is used in conjunction with the <a href="http://www.tdddev.com/2018/01/design-pattern-repository.html" target="_blank">Repository Design Pattern.</a><br />
<br />
I have previously used the Unit of Work pattern only in relation to database operations, but it could be used for file access, other sources, or multiple types together; the key is that all work gets completed as if it were one action.<br />
<h3>
Reasons you would want to use the Unit or Work pattern</h3>
<ul>
<li>Allows for smaller components that do not need coordination logic</li>
<li>More efficient by reducing duplicated or unneeded work, only the final result is stored</li>
<li>Ensures working with up-to-date entities</li>
<li>If one piece fails, all fail, guaranteeing data in a good state</li>
</ul>
<h3>
How do you implement Unit of Work?</h3>
In my opinion, one of the best ways to use the Unit of Work pattern would be for your Unit of Work to be created as soon as a request comes into your system and to be completed right before you return a response. In this way you have one unit of work that captures all changes and gives your entire request pipeline that logical transaction.<br />
<br />
It might look a little something like this:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2hyZj8SEckYe3SiDjDjRifOcp_wkFbAJewQgIu-9B8eHecycFPFgWB6z7cfqdBxuGx5afC49FaToZb67sTbkdd1mT8wupMHp53Rh50YS0L3d4EK3eQ6kHdQLnEL_l6dLV6zCrfPo4snE4/s1600/Screen+Shot+2018-02-20+at+7.58.17+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1190" data-original-width="1138" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2hyZj8SEckYe3SiDjDjRifOcp_wkFbAJewQgIu-9B8eHecycFPFgWB6z7cfqdBxuGx5afC49FaToZb67sTbkdd1mT8wupMHp53Rh50YS0L3d4EK3eQ6kHdQLnEL_l6dLV6zCrfPo4snE4/s640/Screen+Shot+2018-02-20+at+7.58.17+AM.png" width="611" /></a></div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-52908987522910047092018-01-24T07:46:00.001-06:002018-02-20T08:04:35.430-06:00Design Patterns Series<div>
Design Patterns are an approach to solve problems when creating a piece of software. They are useful as a best practice template when solving a problem. They also give you and your teammates a common understanding when discussing how to solve a given problem. That common understanding only happens if everyone on your team knows the patterns. </div>
<div>
<br /></div>
<div>
I am using this space to collect a series of posts that will dig into my understanding of common Design Patterns.</div>
<div>
<ul>
<li><a href="http://www.tdddev.com/2018/01/design-pattern-repository.html" target="_blank">Repository Pattern</a></li>
<li><a href="http://www.tdddev.com/2018/02/design-pattern-unit-of-work.html" target="_blank">Unit of Work</a> </li>
</ul>
</div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com1tag:blogger.com,1999:blog-7827567395977722905.post-3413439524466210462018-01-24T07:45:00.000-06:002018-01-24T07:49:26.862-06:00Design Pattern: RepositoryThe Repository Pattern is a pattern that defines how to access data in a reusable, isolated fashion. The core concept is to isolate the logic required to call a database, file, or other data source. It can be reused without other layers of the software needing to know the details of how to get that data. An example would be the connection string for a database should be used in 1 location, within a repository, rather than every class that needed data needing a connection string.<br />
<br />
The repository is used by calling classes like a collection of data. If I have an employee repository, classes that need an employee can query the employee repository as if all employees were already in an in-memory collection.<br />
<br />
<pre>var employee = _employeeRepository.FindById(1);</pre>
<br />
I view the repository as the bottom layer of code.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4JKQit_dkQCnc3XS31AGw2gdftA8Qz1-b0bwcTVa4Ug6QxlSqGAAuUSj244SiK4HqV1K3QPUe1IodwBM5p4g9puld-4XcA15c6VRxA3HvFf8gbD_s-6rxk_8WdFQ0l5Qox-CDHcmyuOSa/s1600/Screen+Shot+2018-01-23+at+8.54.25+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Code Layers: UI Layer -> Business Logic -> Repository" border="0" data-original-height="820" data-original-width="1166" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4JKQit_dkQCnc3XS31AGw2gdftA8Qz1-b0bwcTVa4Ug6QxlSqGAAuUSj244SiK4HqV1K3QPUe1IodwBM5p4g9puld-4XcA15c6VRxA3HvFf8gbD_s-6rxk_8WdFQ0l5Qox-CDHcmyuOSa/s320/Screen+Shot+2018-01-23+at+8.54.25+AM.png" title="Code Layers" width="320" /></a></div>
<br />
Isolating data access from the rest of your code has multiple benefits. You can easily write tests by faking or mocking your repository. You do not actually connect to your data source in your tests, instead your repository actually becomes an in-memory collection. It also means that you can setup your data specific for each test and know that it will be in a known good state.<br />
<br />
You could also setup caching within your repository which would isolate that logic away from other parts of your system. It also makes it much easier to change how or where your data is stored if you have the need.<br />
<br />
A couple of potential drawbacks come to mind with this pattern. First this could create more classes and files within your project. Some would view this as adding complexity, but I feel the benefits would be well worth it. Another possible drawback could be in optimizing your data access. The defaults for your repository might not be the most performant way to query your data. This is likely not going to be a huge issue unless you are working on something that you need to squeeze out every efficiency to make your project successful. In those cases, you could still utilize the repository pattern, but you would need to do extra work to improve performance where needed.<br />
<br />
<h3>
How I would setup a repository in my code</h3>
You could create a repository for each and every different data object that you needed, but I have found that most repositories tend to share enough common methods that you can start with a generic repository and build more specific ones as needed.<br />
<br />
<pre>public interface IRepository<T> where T : IEntity {
T GetById(int id);
List<T> GetAll(Expression<Func<T, bool>> where);
void Delete(T entity);
void Add(T entity);
T Save(T entity);
}
</pre>
<br />
This interface will likely cover the majority of your needed, but there is always the ability to expand on it when you have more specific queries that you want to reuse.<br />
<br />
<pre>public interface IEmployeeRepository: IRepository<Employee> {
List<Employee> GetManagers();
List<Employee> GetNew();
List<Employee> GetAllByRole(RoleEnum role);
}
</pre>
<br />
With this IEmployeeRepository we get all of the methods from IRepository through inheritance and add onto those the methods that most make sense for employees.<br />
<br />
One thing I came across while researching the repository pattern was that the repository might not need to have a Save function if you use the Unit of Work Pattern. To better understand why that would be the case, I plan to research the Unit of Work Pattern next.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-56850526975102444732017-08-14T07:25:00.003-05:002017-08-14T07:25:47.256-05:00Intern Project, a look back.This summer I was able to be the Lead Developer for our intern team. The team consisted of a developer that was chosen as our Leader, he was able to show his leadership ability in a setting that he would not have otherwise had access to. Myself and another full-time developer helped to mentor the interns and build out the site. And, of course, four interns that are studying software majors at their universities. These four had very limited experience with developing a website before coming to work here and also did not really know what it means to work in an enterprise-level team environment.<br />
<br />
Over the course of 11 weeks, with roughly 50 working days we were able to design a new website and build it from nothing into a fully functioning site that will add value to our business. Everyone had amazing opportunities to learn and grow and come together as a team. The people that we were at the start of the summer are so much better with more knowledge and experience to draw upon now at the end of the summer.<br />
<br />
Here are some interesting stats for the summer.<br />
<ul>
<li>We completed 94 stories, almost 2 per day</li>
<li>634 commits to master, with over 30 branches to master</li>
<li>Over 35,000 lines of code</li>
<li>6 deployments to Production</li>
</ul>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiVOypHn-rWN-QZR4bNAgs51cHaidqTigpcDs2PrVfTCOhZJTtlt9Vh_-S4jAkUfrCbdH8Jm5dQIMz38eTkiTBIUg6Zj9trVB0XweA4lnB5gXsmxwc0oNGux_cigoltclIXqYiYo4DfXVI/s1600/Screen+Shot+2017-08-10+at+9.53.40+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="542" data-original-width="986" height="175" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiVOypHn-rWN-QZR4bNAgs51cHaidqTigpcDs2PrVfTCOhZJTtlt9Vh_-S4jAkUfrCbdH8Jm5dQIMz38eTkiTBIUg6Zj9trVB0XweA4lnB5gXsmxwc0oNGux_cigoltclIXqYiYo4DfXVI/s320/Screen+Shot+2017-08-10+at+9.53.40+AM.png" width="320" /></a><br />
<span style="color: #666666; font-size: x-small;">Work completed by environment</span><br />
<div>
<br /></div>
<div>
The chart above shows the lag in getting work from lower environments through to the higher environments with the green being what is in production. As you can see, we did not have too many large gaps between getting work done and getting it into production. This was a high priority for the team leadership, to get our code out often and not wait until the end of the summer to push 1 large deployment.<br />
<br />
Even though we were not officially launched, it was important to us to get our work in front of users and gain feedback. Our first 2 deployments had some minor hiccups, but solving those issues made the later deployments a breeze.<br />
<br />
The feedback we gained from the early releases by users also helped shape the website. What we designed early on was not what the final product looked like, and we would not have been able to make those changes had we waited until the end of the summer to get our work in front of users.<br />
<br />
The interns grew a ton as developers over the summer. At the beginning none of them was familiar with web development at all, but by the end they all had a good foundation that will serve them in the future. They all got experience with front-end working using Angular as well as server side code written in C#.<br />
<br />
One thing that I took away from the summer was the importance of making sure everyone is on the same page. Too often, I think that I am explaining something clearly, but others are not following along with what I am saying. To help with this, taking multiple different approaches to explaining my ideas is important. Nothing was quite as useful to understanding this summer than when I would draw out the architecture behind what the code was doing, just having a simple visual representation of what I was describing went a long way to getting that understanding we needed. Another valuable tool I used was walking through the code line by line to detail what each line did and why I had chosen to do it that way. Or, reviewing their code in a similar fashion, and asking questions of what could be done differently.</div>
<div>
<br />
Lastly, this summer I wanted to learn for myself if I wanted to be a Lead Developer. Was I a good Lead Developer? Could I help those I was leading become better developers while also succeed at creating a good product. I believe the answer to all of those questions is yes. I would like to be a Lead Developer, I think that I did a good job this summer guiding the interns as the project as a whole. I still have room to improve and working with other experienced developers is different than working with interns, but I think that given the chance I would be able to adapt to those challenges.</div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com2tag:blogger.com,1999:blog-7827567395977722905.post-77729436212860558872017-07-17T07:52:00.000-05:002017-07-17T07:52:00.336-05:00Developer Job DescriptionWhat do you tell people when they as what you do for a living? Do you say that you are a programmer or developer? What if they follow that up by asking what that means, or what your daily activity means?<br />
<br />
I have an answer that I think describes what I do best.<br />
<h4>
Problem Solver</h4>
I am first a problem solver. I generally use technology as the tool to solve problems, but there are also times when a non-technical answer is really the best solution. Being able to break down the problem at hand and see it from different angles always me to provide numerous different solutions, then talking or thinking through those options should lead to the best possible solution. This works very well in a team environment because everyone has different ideas. Someone else will think up other ideas than I will, by sharing our ideas together we can build new ideas together.<br />
<br />
<h4>
Code Author</h4>
When a technical solution is chosen and I start writing code, I shift into a different role, Code Author. Here I am focused on writing the clearest, easiest to read, code that I can. Most of the time the code that I am writing is not unique. There are patterns to use or examples to follow. The most important thing I can do is make sure that the next developer can understand what my code is doing. Much like a author, I want to focus on my reader and not on myself.<br />
<br />Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-43996266260318211442017-06-27T07:44:00.001-05:002017-06-27T07:44:23.827-05:00Interns: Taking off the training wheelsMy intern team has been working for several weeks now on our new website. We have already completed one deployment to production and are finalizing our second one. We started with a plan to release often adding small bits of functionality as we go and so far that plan has been working really well. We already feel like we have accomplished a lot because we have completed many of our project's requirements and should easily be able to complete the rest giving us time to do even more than just the original requirements.<br />
<br />
One of the things I have had some difficulty balancing has been how much to lead the interns and how much to let them figure out on their own. In deciding what our team process should be and how we should allocate our time, I think it was important for me to do more leading. I saw some deficiencies in how we were currently working and brought up some ideas for how we could address them. We had moved into spending all our time just working through stories and did not have any dedicated time for learning. We decided that spending an hour or so in the morning for individual learning and an hour or so after lunch to team learn would help us continue to grow and have plenty of time to get work done.<br />
<br />
I had another opportunity where I think letting the interns decide was better than leading them in a specific direction. We had been mentoring with a lot of direct involvement in how to code our stories and solve the problems we encountered. Due to a company event, all of the mentors were away from the office for the day and the interns were left to work on their own. This day allowed them to see that they could work together without our direct guidance and solve their own problems while also learning more. They unanimously wanted to continue that path of working more on their own with us as resources to help them when they got stuck. I could have suggested we take this approach as well, but having them come to that realization on their own was a better decision.<br />
<br />
Now I have shifted more into finding opportunities to give focused training when I have seen a need. All of the interns have a good basic understanding of what they are doing and how to solve their problems, so I can give them some more advanced direction. One thing I have focused on is clean coding practices. We had a fairly complex section of code that filtered a list of data based on multiple points of that data. They were able to come up with a working solution on their own, but it was very procedural and fairly difficult to understand it all as one unit. I guided them in taking that working code and breaking it apart into smaller methods that were easier to understand in isolation. They all enjoyed this refactoring and I don't think they would have learned as much about why you want to have clean code than if we had directed them in writing it that way in the first place.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com17tag:blogger.com,1999:blog-7827567395977722905.post-75470470430630868292017-06-19T07:31:00.003-05:002017-06-19T07:31:27.423-05:00Advice from Dan WahlinDan Wahlin was here this week running an Angular training course.<br />
The Intern team had the great opportunity to steal an hour of his time today to ask questions and learn from an expert. We had some Angular specific questions, but we also got a ton of great life advice.<br />
<br />
These are the biggest take-aways I had from our time with Dan.<br />
<br />
<ol>
<li>His greatest strength is his persistence and ability to work harder than others. He said that he might not be the smartest, even though he clearly is very smart, but that he will out work you and he will solve whatever problem he is facing through his persistence.</li>
<li>He also said that it was important to quiet your inner critic. You should not be afraid to do something, but rather use that fear and "go over the wall, not run away." I have also recently begun reading the book <a href="https://www.amazon.com/dp/B06XRY8SL3/" target="_blank">Banish Your Inner Critic</a>, which focuses directly on this concept and what you can do to change your inner critic, this advice had really great timing for me.</li>
<li>The next thing will not bring you happiness. Early on he was always striving for that next thing, whether it was a promotion, a raise, a trip somewhere, or whatever else. None of those next things turned out to be the thing that finally made him happy. He had to learn to be happy as he was. Once he figured that out everything was happy and he could spend his time being happy doing what he was doing rather than focusing on the next thing.</li>
<li>Always be learning. The developers he has seen be successful are the ones that are always learning and are willing to adapt and change. One of his hobbies is to learn, rather than spending his time with a leisure activity he would rather be reading about a new technology or trying out some new framework. I think this goes along with his persistence in giving him an advantage that most other do not have.</li>
<li>Lastly, some advice for what he looks for when interviewing developers, be willing to say, "I don't know." If you are not able to say I don't know, then you are going to be difficult to work with and he would not be interested in working with you.</li>
</ol>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-85774020566440876022017-06-11T08:33:00.000-05:002017-08-10T09:10:41.322-05:00New role: Lead Dev<div style="font-family: Helvetica; font-size: 12px; line-height: normal;">
<span style="font-size: 12pt;">A few weeks ago I started my new role as the Lead Dev for my company's summer intern project. We have 10 weeks for a leader, myself, another full time developer, and four student interns to join as a team and create a working application from scratch. In the Lead Dev position I will be focusing most of my time teaching the interns and building them up rather than directly coding the application. I will find ways that I can stop hurdles and roadblocks from slowing progress, while helping the interns gain insight into what goes into building an application. </span></div>
<div style="font-family: Helvetica; font-size: 12px; line-height: normal; min-height: 13.8px;">
<span style="font-size: 12pt;"></span><br /></div>
<div style="font-family: Helvetica; font-size: 12px; line-height: normal;">
<span style="font-size: 12pt;">Our first couple of weeks together have not been focused on writing code and more on less technical things. We have done team building exercises and already feel like a solid team with everyone willing to share their own ideas. We have defined the requirements for our project and had sketching sessions to mock up what our application it's going to look like. We have taken those sketches through several rounds of feedback coming up with a better solution than any individual idea we had at the beginning. </span></div>
<div style="font-family: Helvetica; font-size: 12px; line-height: normal; min-height: 13.8px;">
<span style="font-size: 12pt;"></span><br /></div>
<div style="font-family: Helvetica; font-size: 12px; line-height: normal;">
<span style="font-size: 12pt;">Towards the end of this week we were able to start writing code for our actual application. As we have started teaching our technologies, we have taken the approach of all working together focused on the same task. This had worked really well as the interns are getting to see everything that is happening as well as helping each other out if someone gets stuck. We stop to ask questions and work through the thought process a developer would likely use to solve a problem. By the end of the week we had built out a navigation system and a placeholder for each page allowing us to prove out that the navigation worked. It has been super cool to see how much we have accomplished in such a short amount of time. I believe we accomplished so much because the team is lean, focused, and engaged. </span></div>
<div style="font-family: Helvetica; font-size: 12px; line-height: normal; min-height: 13.8px;">
<span style="font-size: 12pt;"></span><br /></div>
<br />
<div style="font-family: Helvetica; font-size: 12px; line-height: normal;">
<span style="font-size: 12pt;">It had been an incredible first couple of weeks. I have learned so much by leading and teaching and not just doing. It had been awesome to see the interns really jump right into their roles and to see how each one learns differently. I look forward to all the awesome things we will learn together this summer and plan to share more here as we do. </span></div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-27519958080296413322016-09-10T20:26:00.000-05:002016-09-11T14:28:10.322-05:00HDC 2016 Keynotes<p>I really enjoyed attending the 2016 version of the <a href="http://careerlink.com/hdc/">Heartland Developers Conference (HDC)</a>. I want to share some of the things that I took away from the conference this year.</p>
<p>The biggest highlights for me were the 2 keynotes on day 1 of the conference. <a href="http://thetarah.com/">Tarah Wheeler</a> kicked off the show with a great talk that focused on mentoring. <a href="http://www.jeremybytes.com/">Jeremy Clark</a> finished the day off with a complimentary talk about how to be more social and interact with fellow developers at events like HDC.</p>
<h3>Tarah Wheeler's Keynote</h3>
<p>From Tarah's speech I gained a lot of encouragement to go forward and work to help mentor others in the community. She has found that when she gives to others that it has opened doors for her in the future. Even just giving someone encouragement can build a relationship that benefits everyone involved. Mentoring doesn't require you to know everything and not even a lot more than the person you are mentoring. Knowing just 1 more thing than your mentee still provides them with knowledge.
</p>
<p>Once you start giving, other will seek to help you. I believe the reason for this is tied to Tarah's advice on who to mentor. She said to look for others that are already giving themselves. If you are giving and your mentee is giving then you form a mutually beneficial relationship. If you seek out someone that is not interested in giving themselves, then you will likely be frustrated by the effort that person gives you back.</p>
<p>Tarah was a great speaker and had a great message. If you have the opportunity to hear her talk, I would highly recommend doing so.</p>
<h3>Jeremy Clark's Keynote</h3>
<p>Jeremy covered 2 main topic. First was User Driven Development. A few of the main points I took away from this keynote were:</p>
<ul>
<li>His biggest successes were when he knew what the customer needed and his biggest failures where when he didn't.</li>
<li>My job, as a developer, is not writing code, it is solving problems. To achieve this, you need to understand the users and their needs not just what a spec tells you to do.</li>
<li>It is important to build trust with your users.</li>
<li>Care about making things better. If you want to make things better all the time, you will have a greater impact than just writing code.</li>
</ul>
<p>He also had a couple of good quotes that can be used as a guiding principle for helping the user. "I fight for the user" and "I need to know the user because the user doesn't know the technology."</p>
<p>And he also had a good story about a place asking him to make the system do what it does today. His response was, "We are rewriting it because it is broken. What it does today is not working." Eventually he was able to come up with a simple solution to solve what the users needed rather than just having it do what it already did.</p>
<p>Then he focused on <a href="http://www.becomingasocialdeveloper.com/"><strong>Becoming a Social Developer</strong></a>. When you are around a group of developers like at a conference, you know 2 things that you have in common with anyone there.</p>
<ol>
<li>You both love technology</li>
<li>You both want to learn</li>
</ol>
<p>So given this knowledge you can fairly safely assume that you and any other developer you are around can find something to have a conversation. You can take a fairly small risk by asking someone if you can join them and they will most likely say yes. Even if they do not, the worst thing that can happen is really not very bad at all.</p>
<p>This part of his talk really synergized well with Tarah's talk. By being more social, and being willing to start conversations, you will create new relationships. Those relationships might lead to opportunities in the future or they may just be a learning experience.</p>
<p>Many developers think that they are too shy to be social in this way. Jeremy said that shyness is a learned behavior and just like any behavior it can be changed. He gave some tips on how to overcome that behavior and challenged everyone to meet someone new at the conference. I was able to complete his challenge and met a few new people. Some of the conversations I had went better than others, but I was able to complete the challenge and should have an easier time of it in the future. </p>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com1tag:blogger.com,1999:blog-7827567395977722905.post-42672178208583795592016-09-02T08:00:00.001-05:002016-09-02T08:00:42.037-05:00Double Back DevelopmentHave you been stuck on a problem at the end of the day only to think about it all night? Then when you start work the next day, you are able to solve the problem quickly. I think I may found a reason that happens.<br />
<br />
I got this idea from listening to this TED talk: <a href="http://www.npr.org/2016/08/26/490625260/can-slowing-down-help-you-be-more-creative">Can Slowing Down Help You Be More Creative?</a><br />
<br />
In this talk, Adam Grant discusses how procrastinating can lead to more original and creative ideas. He found that there is a curve for creative ideas. People that get things done as soon as possible and those that get things done at the last possible moment tend to produce the least creative work. However, someone that puts things off a little is allowed to let new ideas form and still has time to actually implement them.<br />
<br />
One of my biggest takeaways was the idea of, “Quick to start, slow to finish”. To cultivate creativity, you want to start a project off as soon as possible, but then set it aside and leave it alone for a while.<br />
<br />
With this in mind, I am suggesting a different approach to how we develop code. I call it <strong>Double back Development</strong>.<br />
<br />
Double back Development is the idea that you start a feature, you get some of it done, but then you do not finish it. You move on to a different feature. You continue this pattern to get a few different threads going. Then you double back to that first feature you started a while ago. You get to continue work on this feature with fresh ideas. You also have not devoted so much time and effort into it that it feels bad to start over if your new approach requires. I think this will lead to more creative solutions.<br />
<br />
Will this idea work? I don’t know yet, but I plan to experiment and find out.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com1tag:blogger.com,1999:blog-7827567395977722905.post-56488050443298515892016-07-22T08:14:00.002-05:002016-07-22T08:14:21.508-05:00Not or Bang versus Equals FalseI generally write code in C#. There are 2 mains ways that I have seen to check if a Boolean expression returns in the negative.<br />
<br />
Using a bang to symbolize "Not" before the expression<br />
<br />
<span style="color: red;">!</span>(<span style="color: blue;">expression</span>)<br />
<br />
And checking if the expression equals false<br />
<br />
(<span style="color: blue;">expression</span>) == <span style="color: red;">false</span><br />
<br />
<span style="color: red;"><span style="color: black;">I have gone back and forth between using both never really having a strong feeling as to which I prefer.</span></span><br />
<br />
<span style="color: red;"><span style="color: black;">Today I have decided that I believe one is better than the other.</span></span><br />
<br />
<span style="color: red;"><span style="color: black;">I came to this conclusion by really thinking about the <a href="https://en.wikipedia.org/wiki/Principle_of_least_astonishment" target="_blank">Principle of least surprise</a>. The principle when applied to coding is that you want your code to not surprise the next developer. What can you do to make your code easy to follow and understand?</span></span><br />
<br />
<span style="color: red;"><span style="color: black;">Viewing these 2 options under the lens of the Principle of least surprise, I think one is clearly more surprising than the other. I think that using the bang before an expression is much more surprising than equating the expression to false. The little exclamation point can get lost while reading code, especially complex code. </span></span><br />
<span style="color: red;"><br /></span>
<span style="color: red;"><span style="color: black;">Now I will use equals false going forward to make my code as unsurprising as I can.</span></span>Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com2tag:blogger.com,1999:blog-7827567395977722905.post-34083150242225753192016-07-06T07:49:00.001-05:002016-07-06T07:49:18.379-05:00Team SharingI work for a company that has multiple developments teams all working on different projects. Some teams work closer together towards a large goal, while others can be somewhat isolated. One team may work large on a web project while another is focused on mobile and another still could be just back-end services. There is collaboration between teams when it makes sense or one team depends on another, but I wonder if there aren't more opportunities to share knowledge and get teams to learn from each another.<br />
<br />
My idea is to have 1 week where a developer from each team would join another team. The developer that changes teams would join their new team as if they were a new hire of that team. They would get great exposure to how that team works and would also get to work on something different than their normal project. With every team sharing a developer, each team would get fresh ideas and views of how they work. After the week was over, the returning developer would have new knowledge to share from the team that they worked with.<br />
<br />
Working with a different team for a week could also create new lines of communication as 2 people that might not have otherwise had a chance to work together would now know more about each other. I believe team sharing would create more of a community between teams. I also think this could boost morale by changing things up a bit and having that feeling of newness.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-64236229287387441242016-04-17T07:43:00.002-05:002016-04-17T07:43:13.584-05:00Say Yes<span><span>I recently went on a team outing where we took an improv class. One of the ideas of the class was that you need to accept the idea provided by your partner(s) in the scene. If you contradict that idea then you are taking away from what they are trying to build for the audience. The core idea is to "say yes" and go with the flow of the scene. This will tend to lead to funnier moments than if you are are fighting against your partner(s).</span></span><br />
<div>
<span><br /></span></div>
<div>
<span>This made me think about how life outside of improv and comedy is normally not this way. The instructions to the class to "say yes" are needed because this is not the way most people behave most of the time. How often do you hear someone disagree with a suggestion someone else gave them? It's almost like a reflex to some people. No matter what the suggestion is or who it came from they disagree with it immediately and clearly couldn't have considered the suggestion. I wonder if that sort of mindset leads to a negative outlook on life? By always being negative you only see the world through a negative lens. </span></div>
<div>
<span><br /></span></div>
<div>
<span>I think it would be better to try to be the opposite. Say yes. If you are given a suggestion, start out by accepting it as a good idea and that you should follow the suggestion. If you start in a positive place and you come to the conclusion that you should not follow the suggestion, then at least you reasoned out why it wouldn't work as opposed to dismissing it out of hand. You will have a solid reason for not following the suggestion and you will have thought through your options. You will likely be grateful for the suggestion and feel like it helped you understand your situation better, rather than thinking of it as a waste of time or a hopeless idea that would never work.</span></div>
<div>
<span><br /></span></div>
<br />
<div>
<span>I also think it is a good idea to say yes when someone asks you for a favor. It is generally going to be easier to just say yes and do a quick favor for someone than saying no. Most people are not going to bother you with some overly complex and difficult task, they are going to ask for something simple and something they themselves would be willing to do for you in reverse. If your first reaction to, </span>"Hey could you grab me that item over there?" is yes of course, then both of you are going to end up happy. The person asking gets their item and you never let negative thoughts enter your mind so you are happy to have helped. If instead, your first reaction is "I don't want to do that," chances are you are going to end up doing it anyways so that you don't look like a jerk. The other person is going to either be happy if you hide your annoyance well or feel bad that you are annoyed and probably not want to be around you as much. You are going to be annoyed and unhappy over something small and insignificant. </div>
<div>
<span><br /></span></div>
<div>
I know that for myself I do not enjoy being around people that are always negative. I do not like talking with people that immediately shoot down my ideas without thinking them through. I want to be happy and positive and if someone does not help me achieve that, I would rather spend time with someone else than them. I believe that keeping yourself in a positive mindset will lead to a happier life. If you do not fight against things and go with the flow, people will be more interested in being around you. You will likely have better and more experiences as well because people will invite you to do things with them rather than avoid you whenever possible.</div>
<div>
<br /></div>
<div>
Say Yes. Stay Positive. Be Happy!</div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-13820971208124151732016-04-08T07:56:00.000-05:002016-04-08T07:56:05.358-05:00Take a step back and understand what your code is doing (Refactor)<span><div>
<span>I was recently fixing a bug in some code and while I was figuring out what the problem was I came across some code that looked something like this:</span></div>
<div>
<span><br /></span></div>
<div>
<span>If x == 1 Then</span></div>
<div>
<span> doWorkBasedOn(x)</span></div>
<div>
<span>Else</span></div>
<div>
<span> doWorkBasedOn(x)</span></div>
<div>
<span><br /></span></div>
<div>
<span>No matter which path the code took the result would be the same as just calling doWorkBasedOn and passing x as the parameter.</span></div>
<div>
<span><br /></span></div>
<div>
<span>My assumption is that someone started this code doing the check for x and then calling doWorkBasedOn(x) assuming that future logic would not always result in the same path. Then someone else, I hope, came in and added the else statement to get their story completed without really looking at what the previous code was doing.</span></div>
<div>
<span><br /></span></div>
<div>
<span>Regardless of how the code got to this state, the last person to work on it should have taken a second to step back and look at what they were doing. Because this code was needlessly complex, a bug was introduced. Had this been done without this extra complexity it would have worked correctly the first time. If at any point someone had really looked at the intent of this code they probably would realized that it was doing more than it needed to. <br /><br />I would suggest to take a step back and look at what your code is doing before and after you work on it and see if there is extra complexity that you can remove. This will keep your code base as easier to understand and less likely to contain bugs.</span></div>
</span>
<br />Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-41950164466116223032016-04-03T14:05:00.000-05:002016-04-03T14:05:32.051-05:00The role creativity plays in programmingI consider myself to be a very logical person. I tend to favor practicality to aesthetics. I feel like this lends itself well to being a developer. I think that logic is seen as a key trait when looking for a developer. I agree, a big part of being a good developer is about being able to think through a problem logically and come to a conclusion that will solve the problem.<br />
<br />
I think that one thing that separates really good developers is that they have at least some amount of creativity. Logic allows them to see the problem and work through how to best solve it given their past experience and knowledge. Creativity allows them to see a problem differently and come to a solution by seeing how things can work in a way that they have not done before. Creativity allows for connecting ideas not previously used together to creates something new.<br />
<br />
If you want to improve yourself as a developer, I would suggest that you do something creative outside of work. Expand what you do and gain new experiences. If you can't think of anything that you do that is creative, start. Take a painting class. Go to a park and draw something. Try doing some acting or perhaps singing. Taking photographs can be a form of creativity. It requires you to view the world around you in a different way and figure out a way to capture it. There are many different ways you can express creativity. If you don't like one activity try something else until you find something that you do like.<br />
<br />
I write this blog. It works a different part of my brain than what I do day-to-day. I get excited when I get an idea for a post. I have some vague idea of what I want to get across in the post and I get to go on a journey to discover how to express that idea in words.<br />
<br />
Have fun exploring your creative side. If at first you do not feel like you are very good, but you are having fun you should keep doing it. The more you work on your creative activity of choice, the better you will get at it. So try out some creative activities and see what you enjoy.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com3tag:blogger.com,1999:blog-7827567395977722905.post-62025531938515873032016-03-14T07:51:00.002-05:002016-03-14T07:51:38.202-05:00Innovation Friday
<span></span>
<div>
<span>Google famously had the concept that their employees could use 20% of their time to work on anything they wanted. This was meant to give their developers time to experiment and try out new ideas that they wouldn't have otherwise had time for. Sometimes these ideas turned into products and most of the time it didn't, but I bet their employees were always learning something that made them better and benefited the company as a whole.</span></div>
<div>
<span><br /></span></div>
<div>
<span>Most companies are probably not likely to want to "give up" 20% of their employees' time in this same way.</span></div>
<div>
<span><br /></span></div>
<div>
<span>My company generally has an all developer meeting on the 1st Friday of the Month. We get caught up with different projects and a look into what is coming up. We also have a Developer User Group where we will internally have a speaker from one of our teams showcase something they have been working on or something new they learned about.</span></div>
<div>
<span><br /></span></div>
<div>
<span>My thought is to combine all of those ideas into what I call "Innovation Friday." We would start of the day with the meeting and end the day with the Developer User Group. The rest of the day would be devoted to innovation. Developers would not focus on new features that are in process, but instead be able to focus on other things. This could be just refactoring a portion of a system that they see a need to clean up. This could also be spent with members from different teams in an effort to learn from what other teams do differently. It could be developers forming new groups to work on something together, for example and angular directive that would be used by everyone and provide consistency across teams. It could be used for dedicated training as well. Really anything that gives teams a little break from the norm and gives them an opportunity to focus on something different and hopefully solve some different problems.</span></div>
<div>
<span><br /></span></div>
<div>
<span>This would be roughly 5% of an employees time which seems more likely to be approved by the business.</span></div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-91133089666414299232016-01-21T08:16:00.002-06:002016-01-21T08:16:49.139-06:00What if we taught Testing First?I was thinking about how people are taught to program. It seems to me that most of the time, people are taught by quickly creating something. Its a "Hello World" app, or a quick Web page to display something. The idea is that you get to create something quick and easy and experience the thrill that comes along with that. From there you start digging into more complex concepts and with experience you learn how to do everything.<br />
<br />
What if we changed that to writing a test first? What if we used the TDD process of red -> green -> refactor to teach? The code required to write a test would be very simple. A single line for setup, the assembly step of a test. A single line for the system to do work, the act step of the test. Then a single line to prove the work did what was expected, the assert step.<br />
<br />
<pre>[Test]
function GivenInputOfHelloWorld_Always_ReturnOutputOfHelloWorld(){
var input = "Hello World";
var result = Target.Process(input);
Assert.AreEqual("Hello World", result);
}
</pre>
<br />
So the person learning would need to write 3 lines of code to create the test, and it would teach them a ton about how pieces of code interact with each other. They wouldn't be exposed to complex concepts yet, just a simple linear set of commands. They would then run the test, which would of course fail because the Target doesn't exist yet.<br />
<br />
Next is where the coding "hook" happens. You help them write the system under test, at this stage it should be a simple 1 line of execution and spit back out the input. They run the test again and it passes. For me at least, this would provide the same sort of thrill as seeing the "Hello World" example because I just completed my first task. This would introduce them into "game" of TDD where you start with a quest, a failing test, and complete that quest by making the test pass.<br />
<br />
From here you can introduce more complex logic, you continue the process and the student learns how to write code using TDD first.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-90189772605187754532015-11-20T11:50:00.000-06:002015-11-20T11:50:04.238-06:00Why I TDDThis tweet by <a href="https://en.wikipedia.org/wiki/Kent_Beck" target="_blank">Kent Beck</a> explains perfectly why I use TDD.<br />
<br />
<blockquote class="twitter-tweet" lang="en">
<div dir="ltr" lang="en">
what if the problem with TDD is that it is adapted to address a level of anxiety most people just don't experience?</div>
— Kent Beck (@KentBeck) <a href="https://twitter.com/KentBeck/status/667384202501885952">November 19, 2015</a></blockquote>
<br />
When I was first introduced to TDD and Unit Testing, I was blown away by the fact that I had never thought of writing code to test my other code. I would write code and run the entire application to see if the changes I made worked correctly. I would test the happy path and then pass it on to QA for more verification. I knew that I didn't find all of the bugs in the code, but I also wasn't sure what more I could do to find them. I hated when I got bugs back from QA and worse when the customer found a bug.<br />
<br />
I have the anxiety Kent is talking about. It was pretty stressful to deal with this anxiety as I wrote code not knowing how I was going to mess up this time. I would fix something only to introduce a new issue or cause a previously fixed problem to resurface. Then I learned about Unit Tests and TDD and I had a way to alleviate that anxiety. If I was fixing a bug, I could write a few tests that would make sure that bug would not reappear. I could write new code having at least some level of confidence that it would do what I expected it to do.<br />
<br />
TDD became my anti-anxiety medicine. It made my code better. It allowed me to relax more about my code. I've often wondered why others didn't seem as interested in TDD as I am, perhaps it is as simple as they don't feel the same anxiety I feel.<br />
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-23840061778718784192015-10-19T14:46:00.002-05:002015-10-19T14:46:54.372-05:00How to deal with difficult codeI have recently been working on a piece of very complex and very poorly designed code. It has been very difficult staying focused on the task at hand because I just can't keep everything going in my mind. I lose track of what path I was working on or how I got to a specific spot in the logic tree.<br />
<br />
What can I do in this situation?<br />
<br />
Unfortunately, I can't completely rewrite the entire section of code, even though it desperately needs it. Even if I was free to rewrite the entire piece of the system, I don't have a good enough understanding of it to be able to completely rewrite it without breaking it. I can, however, make changes to the code to make it easier to understand. I can accomplish this without changing any of the logic in the code. This will shrink down the amount of code I need to work with.<br />
<br />
I can start by taking a piece of code and break it out into its own method. This new method will do nothing different than what it was previously doing. It will receive a name that will be descriptive of what it is doing. It will separate this code from the larger more complex whole. I can then better understand what this new method is doing while also making the larger method easier to understand and smaller.<br />
<br />
I continue doing this, piece by piece until the original large function is broken down into many smaller functions. Every step along the way reduces the complexity of the original block of code and leaves me with a new method that I can understand more easily. I haven't changed anything about how the code works, but I have made it easier to understand.<br />
<br />
When I find myself feeling frustrated trying to understand some new code, this is what I do. I stop trying to understand it. I break it apart and I turn it into smaller pieces that I can understand. Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com1tag:blogger.com,1999:blog-7827567395977722905.post-9551292279302082662015-09-17T20:16:00.002-05:002015-09-17T20:16:29.036-05:00Heartland Developers Conference 2015I had the opportunity to attend the <a href="http://www.heartlanddc.com/" target="_blank">Heartland Developers Conference</a> this year. I had a really good time. I got to learn from really smart people, catchup with friends, and meet some new people.<br />
<br />
The biggest takeaway I had from this conference was how to evaluate which session to go to. With the first few sessions I attended, I tried to find topics that I already had familiarity with hopes of getting deeper understanding. I came to the conclusion that that was not a good approach. The sessions at conferences are not able to dig very deep into a topic. There just isn't enough time for the speakers to cover a lot of ground. So I changed my plan for which talks to attend and chose the ones on topics that I had no knowledge of. This worked out much better for me. I found a lot more new information and generally enjoyed the sessions more.<br />
<br />
I will highlight some of the other items that I found interesting below.<br />
<br />
<a href="http://swagger.io/" target="_blank">Swagger</a> is an open source abstraction for documenting your REST api with a JSON response. It is available for practically every platform.<br />
<br />
HTTP2 is coming, already available on some platforms. Should help reduce overhead of web requests. Shrinks the size of headers. If a header value is unchanged, it does not need to be sent. The server will know if you request an HTML page that you will be requesting CSS and JS files next, and begin sending them before the client requests them. It will be able to do that through remembering how previous requests were handled, not by parsing the HTML file. The client can also tell the server if it has a cached version of a file and does not need it. Sounded like it will make some really nice improvements without breaking how things work currently.<br />
<br />
<a href="http://www.bitnative.com/" target="_blank">Cory House</a> gave a talk on "Owning the technology adoption curve." I really enjoy his talks, every session I have attended by him has been really great. He detailed the adoption curve, from early adopters through mainstream and to strategic laggards. Each spot had its positives and negatives. The biggest thing I took away from this session was, "Don't have a fixed mindset. You can learn anything if you work toward it." The example he gave to further explain this concept was, "Don't say I am shy and awkward. Say I need to work on my social skills." I think too often people assume that someone that is successful just has a natural gift, but they have worked hard to get as good as they are. If you know that you have a weakness or if you are not as good at something as you would like to be, realize that you can get better. It may not be easy to improve, but if you work at it you will get better.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-19929452651534699482015-08-26T20:44:00.000-05:002015-08-26T20:44:00.856-05:00Finding HappinessI listen to a lot of podcasts. They are great for entertainment as well as education. I finished listening to a recent podcast by Tim Ferris in which he interviews <i><a href="https://angel.co/naval" target="_blank">Naval Ravikant</a>. </i>The entire podcast was great, but one part really jumped out at me. You can find the podcast <a href="http://fourhourworkweek.com/2015/08/18/the-evolutionary-angel-naval-ravikant/" target="_blank">here</a>, and I have detailed below what I found so enlightening.<i></i><br />
<i><br /></i>
<b><i>“Desire is a contract you make with yourself to be unhappy until you get what you want.” </i></b><i>– Naval Ravikant</i><br />
<br />
This is the pull quote for the podcast, so it must have struck Tim in a similar way that it struck me.<br />
<br />
I have experienced this, but haven't been able to see this wisdom before. When I want something really badly, it consumes my every thought. Then of course, once I actually obtain whatever it was, it doesn't actually make me happy. At least not to the extent that I was unhappy before I got it. Thinking about a desire with this mindset really changes the desire's affect on you.<br />
<br />
Naval then continues with, "In any situation in life you have 3 options: you can change it, you can accept it, or you can leave it. What is not a good option is to sit around wishing you could change it, but not changing it. Wishing you could leave it, but not leaving it. And not accepting it"<br />
<br />
So he reminds himself anytime that he is unhappy that he needs to just accept.<br />
<br />
I cannot recall the number of times I have thought to myself, or heard someone else "wish" that a thing had happened differently. "I really wish that X, which happened very long ago, had been different."<br />
<br />
You have no ability to change what has happened in the past. Spending any energy or thought on it is just a waste. It's a waste that holds you back from moving on. The only thing that you have power to change, is what is right in front of you now.<br />
<br />
If you have something that you have been holding onto for a long time: think about it, examine it, understand it, and then MOVE ON from it. It is over now. You can't do anything to change it.<br />
<br />
When you are next faced with a difficult situation: think about it, examine it, understand it, and then chose to either change it, accept it, or leave it. Once you have made a decision, stick with it and move on without "wishing" changes in the future.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com2tag:blogger.com,1999:blog-7827567395977722905.post-14740416539486866832015-08-22T12:06:00.001-05:002015-08-22T12:10:38.669-05:00Using tsUnit to Unit Test TypeScriptI have been working on a project using TypeScript and needed to use TDD to build up some of that project. I wanted to find a way to write my Unit Tests in TypeScript so that I could continue to practice TDD and ensure that my code’s logic was sound. I found <a href="https://github.com/Steve-Fenton/tsUnit">tsUnit</a>, a TypeScript Unit Testing Framework. The documentation explains pretty well how to get started with simple unit tests.<br />
After getting a simple test running, I found the need to have a setup function happen before each of my tests run. I couldn’t find any documentation on how to accomplish this from the github documentation or through some quick Google searching. If I want to have something run once before my tests start up I can use the constructor of the TestClass, but I needed this to happen before each test so that they are in a known good state. I found the answer by digging into the tsUnit.ts file itself. To get a function to happen before each test, use the setUp function, this name is the same as the attribute that NUnit uses.<br />
<pre><code> constructor() {
super(); //Make sure to call super or TS compiler will complain
console.log(“Once before any test");
}
setUp(){
console.log(“Before each test”);
}
</code></pre>
Now I have a few tests defined, I have the data I am using being reset before each one runs and I have the tests’ output on a page so that I can see the results.<br />
TypeScript itself also provides some value to TDD. I can write a failing test that expects a property or function to exist before it has been defined and the compiler will let me know without needing to run the test that it isn’t going to work. I think thats one of the reasons I have been drawn to TypeScript, it can remove a class of errors at compile time rather than run time.Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-26699644375850460382015-06-24T07:21:00.000-05:002015-06-24T07:21:28.873-05:00Mapping ObjectsMy purpose for this blog is to share what I learn as I become a better developer. Sometimes I have thought of an idea for a post but haven't come up with enough content to finish the entire post. I had a feeling like a post needed to be a certain length before it would be worth posting. That idea doesn't completely mix with my purpose for the blog. Sometimes you don't learn things in a large post, sometimes its just a little nugget of knowledge that doesn't require a ton of explanation.<br />
<div>
<br /></div>
<div>
With that said, something I recently relearned is that mapping objects to other objects, especially with different property names is a bad idea. It leads to confusion when working with the code. It also creates more opportunities for bugs to exist. So if you need a property from one object to map to a property on another object, use the exact same name. And if you can just use the original object without mapping to another object, that is even better. </div>
Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0tag:blogger.com,1999:blog-7827567395977722905.post-219405727135913182015-06-20T07:44:00.002-05:002015-06-20T07:44:39.543-05:00Training With Dan WhalinI had a great opportunity this week to be a part of a training course given by <a href="http://weblogs.asp.net/dwahlin" target="_blank">Dan Whalin</a>. The focus of the class was on AngularJS, JavaScript, and a little bit about TypeScript. I learned a ton during these few days and want to share some the key points that I took away.<br />
<br />
First, Dan is a great teacher and presenter, if you have the chance to take one of his courses or see him at a conference, I would highly recommend doing so.
<br />
<br />
<h3>
Day 1 JavaScript</h3>
Naming functions in JavaScript you should be consistent. A Good practice to follow is:<br />
<ul>
<li>Anything that needs to be "newed" up should be Pascal Cased (Upper first)</li>
<li>If the item is static it should be camel cased (Lower first)</li>
</ul>
<div>
If you have a function that accepts many parameters, change it to only accept one object with properties for all of the parameters you will need. Then when calling the function you can call using an object literal. This prevent parameters from being passed in the wrong order. Since JavaScript is dynamic it also become easy to add more parameters.</div>
<div>
<br /></div>
<div>
<b>Think in terms of Objects, not just functions. </b>Just because everything in JavaScript is a function, doesn't mean that you can't treat them like Objects. Continue to use the knowledge you have of other languages and how you separate code into smaller pieces.<br />
<br />
Inheritance in JavaScript.</div>
<ul>
<li>Object.Prototype, the object's prototype is a pointer to prototype, not actual inheritance.</li>
<li>Function.prototype, same as object, points to Function.prototype.</li>
<li>Adding a function to the prototype keeps only 1 in memory, versus 1 for each instance of the function.</li>
<li>Prototypes are like a linked list or the Chain of Responsibility pattern. Each stop checks itself and then moves up the list until it either finds something that matches or reaches global.</li>
</ul>
<div>
Using prototypes will improve performance and increase reusability of your code.</div>
<div>
<br /></div>
<h3>
Day 2 AngularJS Services</h3>
An idea that occurred to me was that if you are building different components in Angular and separating each into its own folder, you could create a readme file under each folder for that would be specific to that component.<br />
<ul>
<li>Could contain details on things that should be refactored</li>
<li>Should contain details on dependencies and references</li>
<li>Living document of the component and what it does</li>
</ul>
<div>
<br /></div>
If you are writing unit tests for Angular, you can write a test that will verify a function exists.<br />
<br />
<pre><code>expect(angular.isFunction(factory.get)
).toBe(true); // Test for function to exists</code></pre>
<br />
Example of setting up a factory in Angular. Biggest change from what I used to do is the var injectParams above the function definition and then the $inject below. This passes JSHint checks for objects being defined before they are used.<br />
<br />
<pre><code>(function(){
var injectParams = ['$http'];
function Factory($http){
return {
get: function(){}
}
}
Factory.$inject = injectParams;
angular.module('app').factory('Factory', Factory);
});</code></pre>
<br />
The main difference between a Factory and a Service is that a Factory should return a custom object, but in a Service the returned Function is the object.<br />
<br />
Following naming conventions a Service should be camel cased because it should not be "newed" up.<br />
<br />
For $http calls, success should only be used when it is the end of the road. If you need to do logic or data manipulation, you should be using the .then. The reason for this is that success happens immediately and if you need to do work on the returned data, you might have timing issues. From success you get the ready to go data, but from .then you have to unwrap the data.<br />
<br />
An idea that came up is for components with many binding or properties being watched upon is to have 1 directive watching events within that component, and then have it update only the data that needs changed. This could reduce the amount of resources being consumed and make the component more responsive.<br />
<br />
<h3>
Day 3 AngularJS Routes and Controllers</h3>
<ul>
<li>$routeProvider.when => where to go when the route is hit.</li>
<li>$routeProvider.otherwise => what to do if no rules match.</li>
</ul>
.resolve allows for you to do work before routing.<br />
<ul>
<li>Might be useful for roles or permissions. Call to server before letting the user get to the destination page.</li>
<li>Defines properties that are injected into the destination controller.</li>
<li>The property name on the destination controller needs to match the name in the .resolve.</li>
<li>Could do work in resolve before passing onto controller. .reject on the returned promise should stop the route from happening (also good for permissions).</li>
</ul>
There are a couple of different ways that you can make templates more efficient.<br />
<br />
<ul>
<li>Can embed templates in script tags on html with id used as the templateUrl. That way the template is loaded with the original html call and no extra trip to the server is needed.</li>
<li>Can write to $templateCache in app.run. Would allow for templates to be saved in cache.</li>
<li>Gulp can wrote into $templateCache with a task. This loads all views into cache for you on build.</li>
</ul>
<br />
Per Dan, use Gulp if you aren't already using a JS builder and need to start using one.<br />
<br />
Routes can use route parameters, like id<br />
<br />
<pre><code>.when("/editCusomter/:customerId")
</code></pre>
<ul>
<li>* can be used as wildcard to allow anything after the *.</li>
<li>? will make the property optional.</li>
</ul>
use $routeParams in the destination controller to pull route parameters out of the URL. $routeChangeStart broadcast from rootscope allows for handling of changing routes. This is another area that permissions could be handled. Could also be useful for redirecting and back button.<br />
<br />
Dan shared this piece of code with us:<br />
<br />
<pre><code>var path = '/login' + $location.$$path;
// $$path is where they want to go. Used as a redirect param in route.
$location.replace();
// Removes current path from stack. Needed for back button to work properly.
$location.path(path);
// Redirects to new path</code></pre>
<br />
If you are using routes to redirect users and they are unable to use the back button to get where they came from, you probably need to add something like this to your redirecting. If the user wants to get to a specific page, but needs to login before you allow them to that page, they will go to the page they want, unauthenticated, and then be forwarded to login. Their back button stack now looks like this: <b>homePage => editPage (unauthenticated) => loginPage</b>. If the user hits the back button on the login page, they are not taken back to the home page that they think of as their last page, but instead taken to the editPage (unauthenticated), which then redirects them back to the loginPage. So this code removes that middle page from the stack, which allows the back button to end up on the home page as the user would want. It also appends the location they wanted to end up. You would need to setup some more routing logic to handle this, but it will allow for the user to be redirected to the editPage (now authenticated) after they login, which is where they wanted to go.<br />
<div>
<br /></div>
<h4>
Controllers</h4>
Using controllerAs allows for assignment of properties without injecting $scope, uses "this". This gets you closer in line to using ES6 type syntax. Will still need to inject $scope for watches or $on, anything not a defined property of the controller.<br />
<h4>
Scope Life Cycle</h4>
If you hit the digest cycle maximum of 10, then you are doing something wrong. The only reason you would see this error is if you had properties that kept changing each other back and forth. The digest cycle loops through all watches when anything in scope changes. Then continues to loop until nothing is left that changed.<br />
<br />
On a scope, if you call $digest, it will work on the changes for just that scope. This could be handy for very specific edge cases, but if you are architecting your code you probably shouldn't need to use this. Look for a way to reorganize your scopes and bindings to be more efficient.<br />
<br />
There are 3 levels of watches, each with a different level of specificity:<br />
<ul>
<li>false is default: reference watch. watches for reference in memory to change. Fast and Efficient.
<ul>
<li>Checks by reference using ===</li>
</ul>
</li>
<li>true: value or equality watch. watches for any value change in the item being watched. Slowest, but most precise.<ul>
<li>Check by Equality using angular.equals()</li>
</ul>
</li>
<li>watchCollection. More efficient than true, but less precise.</li>
</ul>
If you are using a watch with true, you should make sure you need it. A "true" watch does deep watching and could be a performance problem.<br />
<br />
Instead of using watch you can use ng-change on any control with ng-model. Depending on what your needs are, this might be more performant.<br />
<br />
ng-model-options can be used to set updateOn: 'blur' to trigger changes only on blur and not on keyup. This could come in useful for not firing off events every time a button is pressed, but instead when the user changes focus.<br />
<br />
ng-pluralize will allow for changing wording when count is 1 versus many.<br />
<br />
ng-repeat will render much faster if using track by anything. Lets Angular optimize some of the bindings.
<strong>Check your ng-repeats and make sure you are using trackBy.</strong><br />
<br />
<br />Christianhttp://www.blogger.com/profile/12227453197232167761noreply@blogger.com0