The general definition associated with decentralized applications (DApps) is an application that functions through a peer-to-peer network as opposed to a single source or computer. The existence of such an app in cyberspace does not depend on a single authority. It can operate under a blockchain network or any other form of the peer-to-peer system (read more about blockchain here). Moreover, it is important to understand that the definition of these applications can differ with respect to the institution. The notion of blockchain originates from the concept adapted by bitcoin which uses cryptographically-stored records. There are limited tokens in the system as a means of checking the value of the currency. Different DApps exist for different purposes but the key property of the application is the independence from a traditional single server database.
What’s your favorite chocolate chip cookie recipe? I bet you could ask that question to 5 different people and get 5 totally different recipes… brown sugar vs white sugar, cake flour vs all purpose, dark chocolate vs milk chocolate. All of these recipes result in a chocolate chip cookie but the process by which we get there is a matter of personal preference. If you were to ask multiple developers to solve a problem, it’s doubtful that any two developers write identical code. It’s not that any one solution is necessarily better than the others… the resulting code is likely just a matter of personal preference.
Grio has adapted the Agile methodology to our consulting business; and one of our most valued “ceremonies” is the retrospective. We keep these meetings open to all, and the notes from these meetings are in a shared folder for everyone at Grio to read.
Despite having access, I found them “gathering dust” so to speak, and decided to dig through the entire folder to track Grio’s ability to implement the changes proposed and avoid the pitfalls of previous projects. We’re genuinely asking ourselves, “Are we serious about learning from mistakes?”
I’ve explored the overall process of my research here, and have presented the findings in depth to our entire team. There’s some good news, and some work to do; but we’re happy to see that our efforts have created tangible benefits to our team, our clients, and our bottom line.
We’re asking ourselves:
“Are we serious about learning from mistakes?”
Being a new hire can be overwhelming in more ways than one. Meeting new people, learning how the company operates and how to become a successful member of the team.
In order to make this transition smoother, an onboarding process can be put into action. Going through this process typically happens once during the course of employment, beginning at the time of hire. Over time, faces become familiar and the day to day tasks become more routine, minimizing the unknown.
Due to the recent increase of personnel at Grio, it emerged the need of having an automated way of setting up new employers’ machines.
Starting with a brand new machine is always a pain for a developer, and setting it takes at least a couple of days if not the whole first week, resulting in big waste of valuable time. Besides, when a developer starts on a new technology it is not always clear which tools are suggested and which ones the rest of the team are using. Therefore, I have been asked to work as a side project on a way to solve such issues.
Since World War I, a series of continuous shortwave radio transmissions with unknown origins have been broadcast around the world. The source and purpose of these encrypted transmissions is unknown, however, they are thought to hold secret communications sent from government intelligence services to field agents.
In growing companies, as software systems become complex and extensively engineered, maintenance can be a challenging problem. Moreover, when high profile bugs arise and/or a lack of system availability arises, it can have disruptive consequences on a business. Hence there is little room for mistakes in these crucial systems.