Monthly Archives: April 2018

Preparing to Migrate a WordPress Site

Now that I’ve got a functional website built for the MassHOSA project, it is time to start preparing to move it the website to its permanent home. Development has been straightforward partly because it has taken place while the server has been living on my personal virtual private server. With full SSH access to the development server, it was much easier to make server-side tweaks to various environment settings. Many of these tweaks had more to do with my server being misconfigured than with WordPress, however. I am hopeful that the permanent hosting environment that is selected will require minimal modifications. Many of the hosts that we’ve looked at, for example, have environments tailored specifically for WordPress hosting.

To begin preparing, I copied the entire WordPress directory to my local machine using SCP. While this took some time, I wanted to be sure that everything was transferred and remained intact. I did not necessarily trust that FTP was up to the task, as I have had some problems with file integrity after using FTP for large-scale file transfers. While there may have been many other contributing factors, I thought I would try SCP instead this time, at least for the downloading of the website files to my local computer. FTP may be the only option for uploading the files to the new host, as many shared hosts do not allow SSH access.

The next step of the preparation process was to export and download the contents of the database associated with the installation. Choosing how I export the tables is important, because of the limited privileges that may be available for importing the data on the new host. To ensure that I would be able to import the tables on the new host, I used the account used by WordPress to access the database, and exported all of the tables in the database. This way, even if the new host allows only one database, I will be able to migrate all of the necessary tables and simply update the wp-config file to point to the correct database.

Thankfully, if anything goes wrong during the setup of the site on the new host, I have the working installation on my virtual server to fall back on while working things out. I hope that I have not overlooked anything and that the migration will be straightforward and painless.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Be the Worst

At first glance, I thought this particular apprenticeship pattern seemed a bit absurd. The reason I say this is because I couldn’t imagine why anyone would actually want to “be the worst” in terms of skill level and knowledge on a team of seasoned software developers. However, after reading the rest of what the authors had to say in this pattern it started to make a lot of sense. This pattern reiterates some of the ideas presented in other patterns such as “The Deep End” and “Stay in the Trenches.” Essentially, the authors explain that it is more beneficial to be a “small fish in a big ocean” rather than a “large fish in a small pond.” What this means is that by taking on more difficult projects and/or working with more experienced developers you will provide yourself with more learning opportunities and walk away with a number of invaluable skills that you will pick up from your more experienced colleagues as well as your own personal experiences.

The authors note that this idea might seem crazy as it clashes with cultural norms that seem to advocate the idea that one should try to obtain the highest-paying position with the most superiority as soon as possible. They talk about how adhering to this cultural norm can curtail ones own self-development process by getting stuck in a position that lacks any real challenge. Another thing in this pattern that I found encouraging was the testimonials from various software developers describing their own experiences of “being the worst.” While you’d think that being the least skillful and/or knowledgeable team member would be an undesirable experience, all of the testimonials in this pattern seem to illustrate positive experiences of self-improvement and success.

At the end of this pattern the authors suggest that software apprentices should try to reach out and observe teams that operate at a high skill level in attempt to “be the worst” but in way that guarantees personal-growth. I think this apprenticeship pattern has provided me a new sense of confidence going forward. I’ve learned that it is completely fine to “be the worst” in a team of experienced software professionals because when you are, you have the largest number of learning opportunities that help push you further down the “long road” of becoming a true software craftsman.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Practice, Practice, Practice

Summary

On our journey to become master craftsmen and women, we must always remember to revisit the fundamentals. Sometimes, the hours spent learning and becoming better at a new job leaves us little time to revisit the fundamentals. Without the room to make and learn from our mistakes, we risk, as best, stagnating and at worst, reinforcing new, bad habits. We must remember to engage in deliberate practice and avoid stagnation.

My Reaction

I agree with this apprenticeship pattern whole heartily. It can be easy to fall back on our established skill set and neglect the need to practice the fundamentals and not let our basic skills flounder. I have experienced this phenomenon first hand last summer.

The Bachelor’s degree program requires that each student completes a certain amount of subjects that do not, necessarily, pertain to our major. I had managed to get through the initial interview process with the placement agency;  rigorous phone interview; and the first three hours of a gruelling interview. The final interviewer entered the room with some paper and a sheet of coding problems. He sat down and asked me to solve some of these problems. I failed.

I have gone over this interview over and over in my mind. My biggest folly was forgetting to Practice, Practice, Practice. The questions presented were terribly difficult, but my lack of studying became evidently clear at the time.

Before this pattern, I had never heard of a Code Kata. Applying the discipline and mindfulness involved in martial arts to the craft of code seems obvious now. I will be actively seeking out these Code Kata websites and practicing the fundamentals of my craft.

I am not sure there will be a time that I attend a public performance Code Katas, but am happy that I am aware of their existence.  This seems to be a bit more than this pattern is attempting to convey, but for those that this speaks too, I imagine that a public Code Kata may be exactly the type of event that they need to engage in the behavior of Practice, Practice, Practice.
I have already begun to find exercises that test the boundaries of my understanding. I am aware of most of the gaps in my understanding and am aware that there are things that I don’t even know that I am unaware of. I believe that this state of understanding best prepares me to gain new skills while not letting my established abilities languish through misuse.

CS-448
CS@Worcester
Week-11

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Everyone is going to fail at one point or another in our lives.  Those that do not experience failure haven’t tried; failure is a part of living.  The important part is to see what these failures are, see what setbacks you face and what you are going to change moving forward in order to try and keep from repeating the same failures over and over again.  It may also just mean recognizing when things are heading in a direction towards failure and cutting your losses.

This is another apprenticeship pattern that I believe can be applied to any other profession and also extends to all aspects of life.  Early on in my career in the Army, I saw my share of failures and mistakes. The Army knows that this will happen and that is a big part of basic training.  Making mistakes and realizing that a lot of the time it is not the end of the world. The important part is to not dwell on your mistakes and feel sorry for yourself, but instead to identify what caused the failures and change your habits or actions to prevent that mistake from happening again.

Starting at a junior position I will be in a position to make plenty of mistakes and fail multiple times.  I am excited about this opportunity because while I understand that failure should not be celebrated and we showed be striving for success, it does give me the chance to learn and grow in this field.  It will give me a chance to stumble and interact with my superiors who will provide guidance and pass along what they have learned. If I stay away from any position or role that has the opportunity for failure means that I have also stayed away from any role or position that gave me a chance to succeed and progress toward a mastery of the craft.  Taking risks and running the possibility of failure is what will help me grow in this trade and pass that knowledge along to others that I work with and those that come after me and hopefully leave the field a little better than when I came into it.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Share What You Learn

Share what you learn is a pattern that believes that in order for new apprentices and others to learn we need to share what knowledge we have.  This is a very important apprenticeship pattern that is looked over often. Passing along your knowledge is what allows future generations to improve standards and practices.  It may also help your peers fill in that missing piece that they may need in order to complete a large project that they are stuck on. With the advancement in technology, it is easier than ever to share what you have learned with almost anyone around the world.

My past work experiences have instilled in me that this is absolutely true.  When I joined the Geek Squad at Best Buy I had a base level of technical knowledge but was not an expert by any means.  Thanks to the other employees sharing what they knew as I watched on for the first few weeks. This allowed me to take in and learn from what they already knew instead of being on my own to figure out what the specific problem was, research the different possibilities that could have caused this to occur, and finally trying the different solutions through trial and error.  This not only made my life easier but created a better experience for our customers. They got their device back sooner because we already had a good idea of what the problem was and they were able to start from the most likely solutions and work out from there. It also made them feel more confident in our abilities to work on their unit. While some may know that there can be different causes for a problem and a solution could be as easy as turning it off and on again, most customers that I interacted with did not know or understand this concept and would sharply lose confidence in us if we were not magically able to touch the device and have it fixed so the quicker we are able to do so the better.

As a brand new apprentice, I will not have the ability to follow through with this pattern right away I will be able to, and plan to, take full advantage of others sharing what they have learned and absorbing as much information as I can to better contribute to the team and the final products.  I do believe that it is a very important pattern and as soon as I am in a position to help pass any knowledge that I have along to others in order to help them improve and develop in their trade I intend to take full advantage of that opportunity. It will help improve on three different aspects.  First, it will help the apprentice to develop a stronger toolkit moving forward. Second, it will help you develop leadership skills and presentation skills. Lastly, it will help your trade as a whole, having more skilled tradesmen working will help create better products and practices.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 4

At the beginning of this sprint, we assigned ourselves tasks to request server-side code from the AMPATH team, to design a user interface for storing credentials offline, and several tasks related to PouchDB. We decided on a UI where, when logging in while online, a user could check a box in order to store their credentials so they could later log in offline. We created a Balsamiq mockup of this design and began investigating how to store credentials so that they would be accessible offline.

We researched PouchDB to see if it would be easy enough to implement that we could create a simple mock to use in our design. In the end, we didn’t use PouchDB to store our login information. From what we could understand, while logged in, the authentication service stored encoded information about the currently authenticated user in sessionStorage. It turned out to be much simpler to create a way to log in offline by storing the same information in localStorage instead, so that the information persisted even after the session ended. In this way, a user logging in offline could have their entered credentials checked against the information stored in localStorage at the time of logging in online. George posted resources to the team channel so we could understand this approach and was successful in getting this implementation working.

sessionStorage: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

localStorage: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

In addition this sprint, we contacted the AMPATH team to ask whether we were taking an approach they were happy with. They have not gotten back to us yet, so one of our tasks for the next sprint will be to follow up with them regarding this.

A current problem we’re facing with our implementation is that we only have one user to work with. We have no way of checking, for example, that User A can only log in if their entered credentials match User A’s stored credentials, not User B’s stored credentials. We also plan to ask the AMPATH team how to proceed in light of this, and we will possibly request another test user to work with.

Tasks to collaborate with both the team working on the offline database and the team working on encryption carried over from the last sprint. I didn’t manage to collaborate with the latter group, as they’re not far enough along for us to give each other useful information yet.

Our team worked well as usual this sprint, with members sharing our progress with each other and the class on work days, on our team channel, and on the AMPATH documentation channel. I personally spent most of this sprint improving my knowledge base so I could better serve the team in upcoming sprints. It should be easier to create concrete tasks which will get us closer to our goal now that we have a functioning implementation to work with, and I’m looking forward to contributing some work on the front end of the user interface. I think what I’ve been learning about JavaScript, the REST API, and asynchronous functions throughout this process will ultimately be useful for creating or working with any web application which involves authenticating users.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The Deep End

The Deep End pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses an important hurdle any good software developer will find themselves in at least once in their career. Complacency is a dangerous thing and can often cause a person to get stuck in a rut[AP]. People who want to move up in the world have to be willing to take risks and bigger leaps than they would normally feel comfortable doing[AP]. That is what this pattern is all about; taking the risky jump.

If you are comfortable where you are and don’t see a need to move up or change what you do, then making small incremental changes is perfectly fine. However, most people at some point are going to want to really switch things up. The issue is they are often scared because they are not confident that they will be able to succeed with the big change[AP]. If you really want the change you are going to have to be willing to take that risk[AP]. This “big change” could be something like accepting that great promotion you were afraid to take in the past, taking an assignment in a foreign country, or even switching companies[AP].

By taking on roles you are uncomfortable with, you will grow your portfolio, experience, social group, etc. Most of the time the benefits outweigh the drawbacks. However, the pattern notes that you have to be aware of when you are truly getting in over your head[AP]. You have to know when to ask for help or when take a step back and reevaluate[AP]. Don’t feel like you have to do it all on your own simply because you knew the risk you were taking. If you fail, or decide that the change you made is not right for you, it will not ruin you or your career if you take the right approach[AP].

I generally agree with what this pattern has to say. There is certainly risk involved in making a big move, especially if you are comfortable with where you are in your career, but I think it is a risk most developers have to take at some point in order to become a master craftsman. You can’t wait until you are ready to change things up. You’ll never actually end up doing it. There has to be a bit of blind faith. Even if it doesn’t work out, there is such a demand for people in this field you will almost certainly have a soft landing.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s07.html

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 4

During Sprint 4, our team worked individually on different encryption libraries to gain a little more insight into the quality and usability of each one. I continued to research WebCrypto API and found the performance of the library to be much faster than other encryption libraries.

The test platform was a MacBook Pro (MacBookPro11,5) with a 2.8 GHz Intel Core i7 running MacOS 10.13 Beta (17A306f) and Safari Technology Preview 35.


On the WebKit blog, authors noted what they thought the disparity was caused by, “Working with our JavaScriptCore team, we learned that the causes of these pure JavaScript implementations not performing well is that most of them are not actively maintained. Few of them take full advantage of our fast JavaScriptCore engine or modern JavaScript coding practices. Otherwise, the gaps may not be that huge.”  WebCrypto API also boasts better security models and gives an example why: “When developing with pure JavaScript crypto libraries, secret or private keys are often stored in the global JavaScript execution context.” Noting this leaves users extremely vulnerable as “keys are exposed to any Javascript resource being loaded”, and allows XSS attackers to steal the keys. WebCrypto API protects the secret or private keys by storing them completely outside of the Javascript execution context. Implementations on MacOS and iOS are based on CommonCrypto routines “which are highly tuned for our hardware platforms, and are regularly audited and reviewed for security and correctness.” They go on to say WebCrypto API is the best way to ensure the highest security protection. WebCrypto sounds like a great resource for quality encryption services but there are others that perform the same tasks and can do what we want securely. The team has decided to focus on CryptoJS, which in this case I don’t think performance will be a big issue, but will keep this information close because I may need it in the future.

I feel the team worked well during this sprint and learned a good amount amount each library. Respectively we worked on bcryptjs, webcrypto api, pouch-db/crypto-pouch, and forge. All options seemed to get the job done but felt that CryptoJS suited our needs the best, while still keeping in mind the Ampath team might have a different preferred encryption library. We all learned more about encryption, Javascript, and the use of Typescript services. My personal interest in security and encryption has increased after working on this project, and all the news we see every day about the privacy of consumers data being compromised.

The first week of the sprint, I spent researching WebCrypto API, looking for a solution to implement that into ng2-amrs. I found documentation but not many examples of how to implement it in Angular 2. I found examples written in Javascript but had trouble getting things to work. I found it difficult to  translate Javascript into Typescript, and how that is going to used in a Typescript service. While meeting with the team we decided that while the encryption libraries we all tested has their own pros and cons, we decided that CryptoJS best suits what we need to get an encryption service running. CryptoJS has more a little more information on how to implement what we need to get our encryption service running.

 

 

The post Sprint Retrospective 4 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

Highlights

Coming into this sprint, we had a pretty nice groove going on. Team-wise, we had decided on what we wanted to contribute to the on going ampath project and this sprint presented us with the opportunity to start building what we have been discussing. Our task as a team is to build an offline log in capability for the current users on the system. We decided to also get a visual layout of the task we wanted to complete that way we could properly diagram and see what we were building. But to accomplish all this task, we needed to understand how the session service code worked in the application. 

Completed Tasks : 

Although the original tasks we set out to complete didn’t seem too hard, it required many moving parts and sessions to fall in place before we could actually start building it. First and foremost, we as the team needed to contact ampath and verify with them if the approach we chose to address the log in issue was the best way to address the issue and also everything would be compatible with their software. We also needed to figure out how to store user credentials in local Storage so the user can log in when offline. The storage of user data would need a secure database configured. We as a team decided to research pouchDb and look up its implementation. I personally spent a few days reading up on it and began to start implementing git in code. although i could finish building the sample project i was working on, i think i got enough understood that i can help the team should we encounter any problems and depending on our progress as a team, i will probably go back an finish building that local database test app.

Another thing that got completed this sprint was the visual layout of the application and how its offline module was expected to work. We were able to draw  a model of what we wanted to build using the balsamiq tool. after diagraming it, we were able to trace some of the server side code to get a feel for what the program API was like. With this API knowledge, we are able to build and know how to implement new services and functions in the existing application.  Mathew was also able to build a prototype of what we need the application to be doing when we log in.

Looking Forward

We were able to get most of the thing we had initially decided to get taken care of this sprint period. Just like every sprint, there were still a few tasks that were not able to be completed. Mainly because they are an things that need to remain on the board until the project is fully completed. Some of these task included collaborating with other teams to ensure that the technology that is being used is compatible for all factions involved in the project development. we also currently need to create a backend design of the UI using balsamiq. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

This week’s Sprint retrospective we decided to look up different types of encryption services. Everyone had an encryption service that they were to look up and then write a shorts program see how it works. We decided out of all the encryption service out there we wanted to look at crypto-JS, Forge, web crypto, pouchdb, and bcryptjs. The one I researched was forged encryption service. It did do what we wanted however we decided not to use it because it has not been updated in 4 years so since we are working with sensitive data and did not want it to be leaked forge was out of the picture. Pouchdb was another one that we ruled out because this encryption service was made by someone that did it during their free time so it wasn’t updated regularly. The encryption service that we did decide to use was crypto Js because it was the simplest encryption service that we could have used and is not too old and the last update was not that long ago.

Finally, we decide what kind of encryption service we wanted to use. We started to talk about how we encrypt the data that is given to us. Oran gave an idea that we would encrypt the data as it comes our way so it would act like a blanket. Whenever some data such as a string, array, and any other sensitive information would come through the encryption service. It would take that data and encrypt it. However Oren had a colleague that was familiar with encryption services and he told him that data like that should be encrypted already. So that brought up a good point we want to ask Ampath if they have the data already encrypted or is this encryption service itself supposed to encrypt the data that they have. So for now moving forward we decided that we’re going to act like they need the data to be encrypted. We also need to start working with the other teams to know what data that is going to be given us to us and if cryptojs would be able to work with what they are planning.

So for the next week I will be studying up more on crypto Js and then trying to help the team write a basic program that can take inputs and give outputs of strings, letters, and words. I learned a lot about encryption during the week that we were encryption service in the beginning I did not know how the encryption service works such as what was salt and encrypt a string how would it remember what encryption that use to the string and if you were to send it to another device to be encrypted with that device need that same type of program to unencrypted password

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.