We all want to improve, absorbing feedback is the most important step in the process of improvement. Even when we get feedback, we don't know how to act on it.We have good techniques for giving feedback like SBI (Situation, Behavior, Impact) however, it took me sometime to develop a good framework to absorb and act on feedback. Let me start with a real life situation:Couple of years back, I received a feedback, however incapable of acting on it. I was struggling to make the any improvement. During this phase I developed the framework which helped me. This framework has two attributes "Understand Deeply" and "Act Swiftly". Understand Deeply is about understanding the feedback and situations where behavior is depicted so that you can relate to situation. Some situations bring out the same undesired behavior. It is also very important to understand the intent of the feedback. Act Swiftly talks about acting on a feedback, taking steps to implement the feedback and correct the behavior. It is really important to act promptly on a feedback, people are more likely to give feedback if they see action on it.These behaviors doesn't work in isolation but rather has a amplifier impact when combined together.Let's start with first quadrant on top left corner and go anti-clockwise.Insincere quadrant, in this quadrant feedback is well understood however not ready to act. There could be multiple reasons for not acting on a feedback example it requires some fundamental behavior change, requires too much effort etc. One way to change being in this quadrant is try to divide the feedback into small pieces and tackle a piece at a time. Indifferent quadrant this is the hardest quarter to be in where you don't (want to) understand the feedback because intent to act on the feedback is missing. Change needed in this situation is fundamental. Burnout, de-motivation or lack of interest could be some of the reasons. Taking a break sometimes help, if its a team, work or manager related issue changing the team or even company might also help.Next comes Frustrated quadrant where feedback is being acted upon is not getting addressed and all the is going waste. It's best to take a step back to try and understand the feedback more deeply. Same feedback in different situation could have very different meanings.True and lasting change happens when we understand the feedback and act upon it promptly to go through change-learn-improve cycles. Remember when the feedback is well understood it becomes easy to incrementally improve.Hope this helps.
Rust's new async/await feature makes it easy to stop and start asynchronous tasks (from: https://commons.wikimedia.org/wiki/File:Red_and_green_traffic_signals,_Stamford_Road,_Singapore_-_201
In Spanish these are all “dedos,” while in Englishwe can distinguish between fingers and toes. Learning a foreign language can be an incredible experience, not only because you can talk to new people, v
Web accessibility is the practice of ensuring that your website is interactive and accessible to even people with disabilities. Many countries provide laws protecting the rights of disabled persons, therefore it becomes really important to design and develop the website in compliance with those laws and follow web accessibility as de-facto.The blog helps to test your web accessibility.1. Open chrome browser and browse any website. Open developer tools and click on Audit tab. Scroll to Audits section and check the 'Accessibility' option.Web accessibility check in Chrome browser2. Once you click on 'Run audits' button, you will see a message(as shown below). Don't worry, auditing has started.Starting auditing of website3. Once audit is completed, it will generate audit report(as shown below)Audit report for web accessibilityHave a great day !!
One of my work mottos is "support the hell out of each other": helping your friends grow and succeed is far more rewarding than chasing after the next gold star for yourself. While I was at Reify Health I was lucky enough to work with other devs who had a similar ethos. There were no rock stars, and everyone looked out for each other. I'm happy to have gotten to work somewhere where I made real, honest-to-god friends :) During my final weeks there I collaborated with coworkers on an experimental framework for supporting each other in a formal context. This framework would let us explore how to be there for each other in more meaningful ways while maintaining boundaries. This seemed particularly valuable in Reify's mostly-remote environment. With their permission, I'm sharing the initial framework proposal below: The Buddy System This doc outlines a proposal for a buddy system. The main idea behind the buddy system is for us to support each other by regularly spending time chatting with each other about things beyond whatever story is at hand. Exactly what that looks like will be up to you; this doc includes suggestions for how to have rewarding conversations. First, here are some ground rules: Ground Rules It’s confidential. Whatever you talk about remains between you and your buddy unless you say otherwise. This is meant to provide each other with time and space to speak about what’s going on :D It’s completely voluntary. You don’t have to participate, and if you do participate you can shape it however you want to: the frequency and content of chats is up to you. You can opt out or change buddies whenever you want. If you decide to drop out of the buddy system, it’s totally up to you if you want to explain why, or not. The buddy system is meant to consciously cultivate a space where we can be vulnerable with each other; part of making that safe is setting the expectation that people can opt out without having to explain why. By the same token, in joining the buddy system you accept that your buddy may at some point wish to opt or change buddies, and you commit to try to not take that personally if it happens 👍 Every three months we’ll change buddies - this gives us a chance to grow together, and also a chance to keep getting new perspectives by buddying with other folks on the team. There’s no impact on your yearly review. Though “Buddy System” would be a wonderfully Orwellian name for a mandatory chatting initiative. It’s reciprocal. Buddies commit to listening to and sharing with each other. If you feel like you have room to grow with listening or sharing, that’s totally cool - and a good first step is to share that with your buddy :) It’s not hierarchical. Being a Buddy means whole-hearted listening, asking questions, and just being supportive, which is independent of any junior or senior designations. The point is to support each other as human beings, not to meet project objectives :-) Suggestions Tell your buddy what you want to get out of the buddy system. Do you want to talk about your career? Your goals at Reify? How to improve our architecture? By letting your buddy know what you’re looking for, you can get all Jerry Maguire and help them help you. Listen your asses off. Avoid the urge to give advice unless asked for it, but instead try to truly understand what your buddy is saying, and try to help them gain clarity. Potential topics include goal-setting and “life at Reify.” Goal setting: It can be very useful to talk to someone about your broader goals and to have them hold you accountable. Sharing a goal often makes it more meaningful and gives you more motivation to reach it. Life at Reify: We have retros, which are useful, but regular one-on-one conversations also have a place in supporting each other These topic suggestions are not meant to be exhaustive. When asking for feedback, communicate what kind of feedback you want: A pat on the back High-level feedback Nitty-gritty feedback Notes Daniel is acting as facilitator in that he’s organizing discussion about the Buddy System so that we all come to a shared understanding of what it is and what we want to get out of it. However, Daniel isn’t, like, the Buddy System’s owner, and can’t tell you what to do. Some reading this might be uncomfortable with the ideas outlined in the buddy system - and that's totally ok! A key part of the framework is you don't have to buy into it. But I think it speaks volumes about the level of trust and mutual good feeling among the team that almost everyone was excited about it while respecting that we're all different and not everyone prefers the same way of interacting. On the other hand, new hires were especially excited because they felt like it would help them acclimate to their new environment. To me, a team that is enthusiastic about these ideas is a team that I'd want to work with; it's a team that actually likes the idea of relating to each other on a real, human level. One topic that came up was, how is this different from just being friends? Is it really necessary to have a structure that everyone agrees to? Does that bring an element of artifice into friendship? My thinking is that structure is a precondition for vulnerability. Structure tells us to be extra mindful in how we interact with each other, and it provides boundaries (like a clear time limit) to protect us from getting overwhelmed. By designating a time and place to consciously interact with each other, it also resolves the problem of never knowing when is "the right time" to bring something up. This would be helpful for new hires, sure, but even in my personal life I've found that structure is much better at fostering deeper interactions than just winging it. Knowing that everyone is "in it" together and that "it" won't last forever provides a solid foundation for trust. Final note: vulnerability here does not mean you have to spill your guts, emotionally leaking on each other all the time. It does mean feeling safe to express that you're struggling or that you feel dissatisfied or hurt in some way. What are your thoughts? Have you tried something like this where you worked, and how did it go? P.S. Reify is hiring!
Redundant! but why? What about job security? Shouldn't we be consolidating our position instead of going redundant? All these questions are obvious when you read the title of this article. Don't worry, we are not talking about how to get yourself fired but opposite, how to grow faster by making yourself redundant in a role. In a job, we are expected to play roles that are needed from us e.g. program manager, project manager, people manager, technical lead are few roles engineering managers play to be successful. This article talks about how we can progressively outgrow in our current role and start learning (or mastering) the new roles. Transferring responsibilities to people you are managing is the best way of making space for learning something new. Over the past couple of years as a engineering manager, I have been following this philosophy to learn new things. Let's take an example about leading a project to understand this better.Engineering Managers are the backbone of the team. However, they are also the weakest link in the team, often they are the single point of failure. Team rely on them to take crucial decisions. In normal situation nothing is wrong with this arrangement but when they are away (in conferences, multi-day-meetings, holidays or sick) projects gets derailed due to decrease in decision making velocity and lack of process ownership in the team.If EM spends too much time on project execution, they won't have enough time for people (call it 100% harvesting and no investing). In my experience, time spent on people is directly proportional to the happiness of the team which has a flywheel effect on deliverables. On the other hand, unhappy teams leads to lower development velocity and error prone deliverables, which results in managers spending more time on execution.This cycle leads to burnout in managers and also results in unhappy teams which has domino effect on deliverables (poor in both quantity and quality). To avoid this situation most important step for the managers is to automate the execution and funnel more-time in people management and product planning. However, it's not a trivial task and involves rolling out well-orchestrated process changes in small implement-and-improve iterations. For me it took 6 months to achieve a sustainable execution model.This article will take you through the journey of "making myself redundant".Phase 1: "Doing all the things an EM should be doing! Well, I want to change it!" Identifying delegation worthy responsibilities! Question: What are responsibilities my team can own and run?Planning? Retrospective? They do it fortnightly hence have a very good understanding which means they can be independent on this quite quickly.Question: Who should own it? Do we need a new role? What should be responsibilities of this new role?Probably we need a feature/project lead. Who should be a Lead?A Team member.Why don't I ask my team, what they think they should be doing as a Lead?Time for brainstorming: We as a team gathered in a room and listed responsibilities which will be owned by the lead. E.g. updating the project status, finalizing implementation approach, sprint planning,retro, demos (team rotates these) etc. Point worth noting, we didn't define everything, like how to manage external dependencies or how to distribute work. The plan was to start with something small and keep on increasing the responsibilities over the period of time. Why not define comprehensive roles and responsibilities? Defining clear R&R in one go is very easy and leads to very clear paths however it also means decoupled roles which is recipe for disaster when you starting something this big. We can compare it with athlete training, they can't run marathon in first week but distance is increased gradually over a sustainable time-period. Similarly, we decided on some base responsibilities with adequate checks in place e.g. leads can always reassign part or whole of responsibility to me (EM) at any moment after discussion.Is this a good model?There are multiple ways a lead can be trained onto new responsibilities:Coach a lead on everything before handing over the responsibility "Throw them in water and let them learn how-to-swim" give them responsibility and let them ask for help.Start small take a step at a time, keep on adding responsibilities. I personally like the third option as it leads to sustainable handover where everyone gets the time to adjust and iterate.Phase 2: "Attending all the team meetings as a participant."Feature lead is starting to onboard on new responsibilities and taking ownership more and more meetings. However, it will start eating into the capacity of the lead which could be a problem. So, apart from defining some basic responsibilities, we also finalized on a rule "lead should start with 20% time on leading". The idea here is to increase the responsibility and not to make them unproductive.The right mix!As discussed above, listing role and responsibilities helps, however it can also be over-prescriptive. Agreeing on "What needs to be done", "When it needs to be done" in important whereas "How" can be left open.Ask pointed questions, to make sure things are on track, it will surface the trade-offs and flaws. Follow five Whys approach if and needed.Phase 3: "Coaching the lead!"As lead is taking responsibilities, start spending more time with them to make sure they understand why we are doing something instead of just doing it for the sake of it. This will lead conversations on "why this and not that", addressing these questions is like laying the foundation of the leadership, answering every question sincerely will help in developing a good leader for your team.Healthy team is build on healthy processes"Processes are the building blocks of trust in a team". "Teams who learn to rely on each-other can solve any problem". "If we can define a problem, we can solve it and if we can solve it once, we should solve it efficiently the next time".Healthy team need lightweight (healthy) processes to make sure everything runs smoothly. You can rely on the team and processes to take care of everything.Phase 4:"Give up the power, not the control!"The last piece of the puzzle is patience.Following meetings if well run can help a lot:PlanningStand-upRetrospectivesHealth-monitors SWOTIf teams is not happy and motivated you can't deliver anything worthwhile. Listening to the team's concerns is the easiest way to address the problems. If team is raising a concern it should be fixed, don't apply filters without understanding the problem first. Team will always be motivated if you remove (or help them remove) the impediments, remember motivation is key to the successful delivery. I believe the most important part of my job is to keep the team motivated. I get the real sense of how we are doing as a team from the meetings listed above.Right Now!Phase 5: "Close to doing nothing related to a project execution! \o/Focus on long-term strategy and career planning for the team!"We successfully delivered the project without delay, covering more than we anticipated and removing all the major blockers we faced.As an EM, I need to be do something to keep my anxiety in check.So, I am making sure:Scope is fixed Team stays away from distractions Focus on one thing at a time, minimize context switching Taking discussions irrelevant to the team away from them Address action items on priorityGiving away your responsibilities is not easy and people would be making mistakes like you did when you started. However, how to make this learning rewarding is the challenge. Remember you are learning as much as the other person, you are learning to be patience, you are learning to give away control, you are learning to diagnose problems early, so much learning is involved in this process. These are the building blocks of being a leader, if you can't delegate you can't scale.In the end, learning is an essential part of the growth for everyone. Focus on growing people in your team for the unforeseen results. Encouraging leadership in your team is the best way of growing your team.Try being redundant, its addictive!
Creating and Installng Sitecore PackageCreate Sitecore Package1. Open Sitecore(from where you would like to create package) and click on Package Designer2. Once Package designer panel is opened, click on Item statically and provide all required details as shown below3. After clicking on 'Item statically' option, a popup will open. Choose selected items and click on 'Add with SubItems' or 'Add Items' buttons a. clicking on 'Add Item' will only include selected item and not child items b. clicking on 'Add with subitems' will include selected Item and its child items4. Click on 'Generate Zip' option which will generate the package in .zip format5. Download the .zip file of sitecore package by clicking on download buttonInstalling Sitecore Package1. Open Sitecore (instance where you would like to install package) and click on 'Installation Wizard'2. upload the .zip package to install and click next to install3. During install, Sitecore popup will appear for inputsa. Override - This option replace the entire subtree with the subtree in the package. You have to be very careful while selecting Override option as it may delete all child items if you have not added the Item with child items while creating package. b. Merge - This is safe option which will find the matching items and versions with those from the package but do not replace any subitemsPlease feel free to post your comments in case you see any concerns or like to thank you :).
Before we start installing Solr instance on any machine, we should be clear on few concepts.What is Solr?Solr is Apache's product and a fast open-source Java search server.Why we need it?Solr enables you to easily create search engine for websites, databases and files.How can we install it?You can download any version of Solr from http://archive.apache.org/dist/lucene/solr/. Steps to install after it is downloaded-Extract the downloaded Solr package and copy it on C or D drivePlease make sure latest version of Java is installed on machine. You can start Solr instance by below command: java -jar start.jarBy default, Solr will run on port 8983. However you can change it ../etc/Jetty.xml file. Look for <set name="port"><SystemProperty name="jetty.port" default="8983"></set> and change it.You can keep the below command in .bet file and run it automatically. "C:\solr-6.1.0\bin\solr" restart -h localhost -p 8984Please feel free to send email for any help.
Could not load file or assembly 'Microsoft.Web.Infrastructure, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.What 'Micorosoft.Web.Infrastructure' does?This dll lets HTTP modules register at run time.Solution to above problem:Copy 'Micorosoft.Web.Infrastructure' dll in bin folder of your project and this problem should be resolved. If you have .Net framework installed on machine, this dll should be present on it. You can search for this dll and copy it in your active project folder. Alternatively, you can install this dll using nuget package managerPM> Install-Package Microsoft.Web.Infrastructure -Version 1.0.0Happy coding!!
What do Postgres GiST indexes look like? How are they similar or different from standard Postgres indexes? In the last few posts in this series (http://patshaughnessy.net/2017/12/11/trying-to-represe
Suppose you had a hierarchical data structure in your application - how would you save it in a database? How would you represent a complex tree structure using flat rows and columns? There are a few different, equally valid
In this article I'm going to show you how to set up OpenShift to integrate with Splunk for logging in a Docker container orchestration environment. These techniques could easily be adapted for a standard Kubernetes installation as well! The techniques used in this article are based on the Kubernetes Logging
In this article I'll show you how you can use the shell as an efficient tool to compliment how you use the clipboard.
Text in the command line can quickly get unwieldy. Here are some simple tricks you can use to navigate in the command line.
This week we had the much awaited Node.js 8.0.0 release! Node is getting faster and better all the time. This release also makes the async / await feature available natively. But before we look at async / await let us quickl ...
There are occasions where you might need to have scripts or commands which wait for TCP/IP ports to open before you continue. I've come across this need again and again when working with microservices, to make my life easier I've created a little utility called wait-port which will wait
Being an engineering leader is not an easy task, especially when you are stepping into this role as a first-timer. Seldom you go through a training, however in most situations you are expected to figure it out yourself with little or no guidance. Often leadership demands you to play following roles:People ManagerProduct/Business knowledgeArchitect/Senior DeveloperVision for technologyI will be writing separate blogs to cover the first two roles. For a beginner, last two roles are very important to gain credibility of the team which is the most important factor in succeeding at your job.As a technical leader, you will be facing the challenges from all the directions like decision making, improving team efficiency and choosing the technology roadmap for your team. However, I hope adopting following patterns can help you sail through these challenges.Decision Making: When hit with the problem, as a techie you rely on your technical skills and often start suggesting solutions immediately which is fine in few situations, however in my experience better way would be to ask pointed questions to lead your team in driving the right decision. Questions should be repeatedly asked to highlight the blemishes in the suggested design. For example, "How would you take care of security?", "How are you addressing scalability?", "How would application behave under these circumstances?" and many more.It's easier to jump to the solution by picking up the first suggestion by trusting the loudest (not literally) person in the room. However, as a coach, you should be involving everyone in the decision-making process. Find out what is missing in the room, is it the knowledge, the skill or the participation. You need to create enough opportunities for everyone to participate. To do that you need to think about various factors like structure of the team, personalities in the team etc. These factors can be neutralized to an extent by bringing everyone to a common understanding of the problem. In my experience, following preparation before hosting an important meeting would make it easier:Share a document explaining the problem which can educate the team before the discussionDuring the meeting, explain the problem in detail so that team can align their understandingDo your homework before going to the meeting. This will help you in asking the right questions and guiding the meeting towards the solution. Improving Efficiency: Team delivers to the full potential if they are not disturbed and allowed to focus on the problem. As a leader, think about how the team is getting distracted, how can you make them focus on stories or task in hand? Improve the development processes so that you can minimize the impact on the team. For example, in a production issue churn out the non-technical part and direct developer towards solving the technical problem.Vision for Technology: Successful teams stay ahead of the technology curve. As a coach, you need to ensure that your team is adapting to changing landscape of the technology world. While working with your team to strengthen the technology muscle, you need to start focusing on what should be the future technology platform for your team. If you are not thinking at least 3-months down the line, you will lose the war while you were busy fighting battles.Be sensitive to what role you are playing in your team. You are not a developer anymore, you are a coach and coaching means understanding before suggesting, listening before speaking, advising rather than commenting.As a beginner, starting in the world of unknown unknowns of management, I hope my secret sauce can help you prepare the right dish for your team!!!
Learning programming languages is a skill: do it well and you'll experience one dopamine hit after another as you master something new; do it poorly and you'll feel constantly frustrated and even give up. What follows are the best techniques for learning programming languages that I've picked up over years of teaching programming by writing books and articles, doing talks, and running a training course. Many of these techniques are pulled from books explaining the latest research in efficient learning, and you can find those books (along with other great programming books) at Community Picks: Learn Programming. Test Yourself Constantly to Defeat The Illusion of Competence One of the worst ways to learn is to re-read or re-watch material. This kind of review gives you the feeling that you understand the topic covered because it seems like you're understanding the topic effortlessly. Researchers call this the illusion of competence. A significantly better approach (and one of the best techniques you can employ) is to test yourself constantly. Instead of re-reading what a function or class or object is, ask yourself to define these concepts or use them in a short program; force yourself to somehow demonstrate your understanding. This process often feels uncomfortable, but it's much more efficient at forming long term memories. You can take this one step further and test yourself before you've covered the material by, for example, attempting exercises before reading a chapter. Remarkably, this has also been shown aid memory formation. The impressive impact that testing has on learning is called the testing effect, and here are some specific ways you can take advantage of it: Before reading a chapter or watching a video, try guessing at what you're about to learn and write it down. Try doing a chapter's exercises before reading the chapter. Always do exercises, even the hard ones. It's OK to give up on an exercise and come back to it later (or never, even), but at least try it. (More on this in the next section.) Read a short program and try to recreate it without looking at the original code. Or, go smaller and do this with a function. Immediately after learning a new concept like objects, classes, methods, or higher-order functions, write code that demonstrates that concept. Create diagrams that illustrate concepts, both in isolation and how they relate to each other. Blog about a concept you just learned. Try explaining the concept to a non-technical friend. (I did this a lot when writing Clojure for the Brave and True; being able to explain an idea in layman's terms forces you to understand the idea deeply.) Many of these techniques boil down to write some code! With programming it's easy to believe we're learning a lot just by reading because programming is text-heavy and conceptual. But it's also a skill, and like any other skill you have to perform it to get better. Writing code is the best way to reveal your incorrect assumptions about programming. The faster you do that, the faster you can make corrections and improve. If you'd like to learn more about the testing effect, check out make it stick: The Science of Successful Learning. Take Time to Unfocus If you're stuck on a problem or don't understand something you just read, try taking a walk or even a shower -- anything to enter a relaxed, unfocused state of mind. It probably seems counterintuitive that one of the best ways to get unstuck is to stop trying for a little while, but it's true. The problem is that it's easy for us to put on mental blinders when we're focusing hard on a problem. I mean, that's pretty much what "focus" means. But by focusing hard, we're exploring only a small portion of the solution space. By unfocusing, our unconscious mind is able to explore and make connections across vast swaths of our experience. To me it's like when you're trying to find a destination on a paper map (remember those?). You can unconsciously become convinced that the city you're trying to reach should be right here! in the upper-left qudrant of the map, so you look at it over and over without success. Then you put the map down and take a deep breath and stare at nothing for a minute, and when you look at the map again the actual location jumps out at you immediately. We've all had the experience of having a sudden insight in the shower; now you have a slightly better understanding of why that happens, and you can employ the technique on purpose. Personally, I will actually take a shower if I'm stuck on something, and it's remarkable how well the technique works. And how clean I am. If you'd like to learn more about the focused and diffuse modes of thinking, check out A Mind for Numbers: How to Excel at Math and Science (Even If You FLunked Algebra). Don't Waste Time Being Frustrated Related to the last section: don't waste time being frustrated with code. Frustration leads us into doing stupid things like re-compiling a program or refreshing the browser with the hope that this time it will be magically different. Use frustration as a signal that there's a gap in your knowledge. Once you realize you're frustrated, it can help to take a step back and clearly identify the problem. If you've written some code that's not working, explicitly explain to yourself or someone else the result that you expected. Use the scientific method and develop a hypothesis for what's causing the unexpected behavior. Then test your hypothesis. Try again, and if a solution still eludes you, put the problem aside and come back to it later. I can't tell you how many times I've thrown my laptop in disgust over a seemingly unsolvable problem, only to look at it the next day and have an obvious solution pop into my head immediately. This happened last week, even. Identify Which Programming Language Aspect You're Dealing With Personally, I find it useful to keep in mind that when you're learning a programming language, you're actually learning four things: How to write code: syntax, semantics, and resource management The language's paradigm: object-oriented, functional, logic, etc. The artifact ecosystem: how to build and run executables and how to use libraries Tooling: editors, compilers, debuggers, linters It's easy to get these four facets mixed up, with the unfortunate result that when you run into a problem you end up looking in completely the wrong place. Someone who's completely new to programming, for example, might start out by trying to build iOS apps. They might try to get their app running on a friend's phone, only to see some message about needing a developer certificate or whatever. This is part of the artifact ecosystem, but an inexperienced person might see this as a problem with how to write code. They might look at every line they wrote to figure out the problem, when the problem isn't with their code at all. I find it easier to learn a language if I tackle each of these aspects systematically, and in another blog post I'll present a general list of questions that need answering that should help you in learning any language. Identify the Purpose, External Model, and Internal Model Whenever you’re learning to use a new tool, its useful to identify its purpose, external model and internal model. When you understand a tool's purpose, your brain gets loaded with helpful contextual details that make it easier for you to assimilate new knowledge. It's like working on a puzzle: when you're able to look at a picture of the completed puzzle, it's a lot easier to fit the pieces together. This applies to languages themselves, and language libraries. A tool's external model is the interface it presents and the way it wants you to think about problem solving. Clojure’s external model is a Lisp that wants you to think about programming as mostly data-centric, immutable transformations. Ansible wants you to think of server provisioning in terms of defining the end state, rather than defining the steps you should take to get to that state. A tool's internal model is how it transforms the inputs to its interface into some lower-level abstraction. Clojure transforms Lisp into JVM bytecode. Ansible transforms task definitions into shell commands. In an ideal world, you wouldn’t have to understand the internal model, but in reality it’s almost always helpful to understand a tool's internal model because it gives you a unified perspective on what might seem like confusing or contradictory parts. When the double-helix model of DNA was discovered, for example, it helped scientists make sense of higher-level phenonema. My point, of course, is that this blog post is one of the greatest scientific achievements of all time. Tutorials often mix up a tool's external model and internal model in a way that’s confusing for learners; it's helpful to be aware of this so that you can easily identify when it's causing you frustration. Spaced Repetition Helps You Remember Spaced Repetition been proven to be one of the best ways to encode new information in long-term memory. The idea is to quiz yourself at ever-increasing time intervals to minimize memory decay using the fewest number of repetitions. The Guardian wrote a great introductory article. Sleep and Exercise Take care of your body! It's more than just a vehicle for your brain. If you want to be able to stay focused and learn efficiently, getting adequate sleep and exercise beats the pants off caffeine and energy drinks. More tips? If you have any useful tips, please leave them in the comments! If you'd like more excellent resources on learning to program, check out the Community Picks: Learn Programming, a community-curated collection of the best books for learning programming. It includes a wide array of subjects, including introductory programming books, books on craftsmanship, and books on soft skills and interviews.
As it turns out this is my 100th post. The first one was published in March 2011 and a lot has changed since then. A lot of new technologies have come in and a lot of my posts have become obsolete. In all these years nothing has created more i ...
In this article I'm going to demonstrate some simple tips and tricks which will help you build and maintain beautifully simple mobile build pipelines. These techniques can be applied to different mobile app technologies and integrated into almost any build system: Each tip is demonstrated in the sample apps in
The Dark Knight came out at the same time that I was becoming intensely interested in Buddhism, and the movie struck me as a kind of extended Buddhist parable, with Bruce Wayne as an icon of the suffering that results from clinging and the Joker as a very fucked up enlightened being. Here are some of my main reasons: (warning: spoilers!) Suffering and Impermanence Buddhism teaches that suffering comes from constantly scrambling for stability in an unstable world. Nothing is permanent, but we strive mightily to hold on to the illusion of permanence, only to suffer when reality once again asserts itself. In the scene where Batman is in the interrogation room beating the stuffing out of the Joker, the Joker just laughs and says, "You have nothing! Nothing to threaten me with. Nothing to do with all your strength." And that cuts to the heart of who the Batman is: a person whose reaction to the first shock of impermanence (his parents dying) was to dedicate his life to developing his strength so that he would never experience that pain again. The Batman's entire being is an exercise in doing just one... more... thing... to establish control. I mean, who would want to live that life? And here's the Joker, ready with the Zen slap: he tells Batman where to find Harvey and his girlfriend Rachel, giving him the illusion of control over who to save. And we know how that turned out: the Joker lied to the caped crusader, telling him Rachel was at one address, but actually Harvey was there. Batman races to save Rachel, only to find find Harvey instead. Nothing to do with all that strength. This really hit home for me because, at the time, I was in a relationship with someone that had a chronic illness. I could try to do everything to make her life less painful and more enjoyable, but there was only so much I or anyone could do. Natural Metaphors and Endless Desire At one point, the Joker says, "I'm just a dog chasing cars, I wouldn't know what to do if I caught one." Or something like that. This is a double whammy: "a dog chasing cars" is totally something a zen master would say, but besides that it expresses our human tendency to constantly strive for the next thing. We're all just dog chasing cars, not knowing what to do when catch one. You get a job: now you want a better job. You get a house: now you want a bigger house. Better to just say fuck it, put on some makeup, and start blowing up hospitals. No Self The Buddhist idea of "no self" is actually somewhat nuanced and I'm purposefully misrepresenting it here, but it would be difficult to argue that the Joker clings to any notion of self in the way that most of us non-enlightened psychopaths do. He gives multiple stories for how he got his scars, revealing the Buddhist truth that our sense of self is just a story we tell ourselves and that no one story is better than any other. He gives up his name and identity to become a fucking clown. And people really hate clowns! Interconnectedness One Buddhist teaching is the idea of interconnectedness: that we are all one, but not in the wavy-gravy way your high uncle used to ramble about. My take on the idea is that it's related to no self: you cannot point to a "you" that is separate from the world you exist in. It's a fallacy to believe your "you" is somehow different from the collection of experiences of the world, so that you are inextricably intertwined with the world. You can't point to one thing outside yourself and say "I am not this," because you are pointing at it you moron, and so in that moment who you are is a guy pointing at that thing, and life is the accumulation of such experiences of things outside of "you." ANYWAY I am totally not your high uncle, OK? Point is, the idea of interconnectedness is meant to foster a sense of compassion. You can see that at the end of the movie when the Joker plays his hilarious "blow up the other boat" gag. Two boats full of strangers become enlightened, refusing to do harm to people they haven't even met.
Web Forms For Marketers has become one of the essential component of Sitecore. Almost every website is using forms to capture the inputs from users and it is very common scenario to get the data stored in Database for reporting purpose. Here are few easy steps which can help you storing the form's data in SQL database.Download the WFFM - SQL Provider(Save To Database) and install it in Sitecore using Installation wizard. All physical files and Sitecore items will be stored in respective location.Once installed, you will notice that it has created a new Action under System-> Modules -> Web Forms for Marketers -> Settings -> Actions -> Save ActionsNow, we have to add connection string in configuration file which will help us storing the data in that database. You have to keep the name of connectionstring to 'wfm' only as same name is referred in WFFM module code.< add connectionstring="user id=your_db_user_id;password=your_db_password;Data Source=your_db_server;Database=your_db_name" name="wfm" >You are done.Now add the 'Save to Database' action on any WFFM form and start using it. Also validate the database and data should start getting stored in it.Furthermore, this module provides the capability of exporting the saved data in CSV format. We can do customization on it to export the data from different servers(CMS or CD) which I will explain in next article.Please don't hesitate to contact me at 'email@example.com' for any Sitecore related query/scenario.
16GB of DDR random access memory my son used in his new gaming PC Recently I’ve been trying to learn how to read x86 assembly language. In http://patshaughnessy.net/2016/11/26/learning-to-read-x86-ass
In this article I'm going to show you how to create a resilient Consul cluster, using Terraform and AWS. We can use this cluster for microservice discovery and management. No prior knowledge of the technologies or patterns is required! The final code is at github.com/dwmkerr/terraform-consul-cluster. Note that