DevOps is more of thinking/culture in software development than a process, tool or technology. In simple terms it is to identify and automate anything that doesn’t need a human brain involvement for developing software. I would like to share my thought on how any team can approach implementing DevOps in their company or project and how simple it is.
Sometimes we know how to use a tool, but we might fail to apply its use at right case. I know these Set methods but never used them for “Math Set” operations. Good to visit basics again 🙂 .
Stemming is the process of reducing inflected (or sometimes derived) words to their word stem, base or root form—generally a written word form. We use different filters in Solr to apply stemming. Each stemmer differs in number of scenarios it can cover. For one of my project we have tried to create a matrix to make decision. It can help you to take decision.
Git has taken source control systems to a new era. I have started my career with Subversion but eventually moved to git. Following are some of the practices which helped me to manage my code well. Most of these are basic guidelines but while listing them here I have realized I am skipping some of them. Its always good have a relook at basics :).
These git basic practices are like TDD and Agile which everyone know but miss practicing because of various reasons which I would leave it to reader ;).
- Pick a branching model, which can make sure
- Developer can switch working on diff features easily. It shouldn’t be like commenting code while you are working on a feature, if you needed to work on something else.
- One place where features developed by teammates can be merged and tested
- One branch which always contains code running in production so that we can fix production issues immediately
- Can accommodate multiple teams with different deadlines to collaborate
- Create branch for every story which might take more than half day. Instead of asking “why a new branch?” lets ask “why not a new branch?”. If not enough reason, go ahead create a branch.
- Do clean/delete the branch once done with that feature.
- Name branch with issue number if you are using any backlog tool. This is helpful for team member to quickly see which branch is for what.
- Try not to use “git add .”. Add one file at a time after checking diff
- Regular committs will make sure you have less files to check and commit
- Make sure your commit message contains issue number you are working on.
- Commit ONLY related files together
- Have your .ignore file updated with all files which need not be committed. When we type “git status”, we shouldn’t see any file which is yet to be committed. Sometimes this needs some work in code to make sure local profile is available.
- Tag commits with releases, major milestones
- git is for source code not for binary files. Do not check-in artifacts. Make use platform specific distribution strategy.
- If you need a minor change in repository of another team, instead of sending mail with lines of code to update, make change and send a pull request
- At least every day/half day, pull changes from integration branch
- If a project is started after successful POC, create a new repository for project instead of reusing PoC repository
- Make sure all repositories are in one of the related organization but not under personal repos
- Sometimes based on context and team structure, you might like to have different repositories for different components. Especially when some of the components are shared components.
- Its always good to give enough thought to give a good name to repository. Name of the repo should give quick glimpse of what it contains. Avoid acronyms unless they are famous. No need to include portfolio name as organization already reflects it.
- README.md file is MUST with
- Some description about project
- URLs for the application
- Important contacts
- Servers used by code in this repo
- Documentation link
- Any code (code in artifact, properties, config etc) must be in source control.
I almost spent a day trying to understand why my unit test case was able to load a resource where as once I deploy the jar failed to load the same. In the end I came across something very basic : Some.class.getResource behaves differently than Some.class.getClassLoader.getResource. There is no simple answer like use this always. It depends on which class loaded loading that particular class. So if you are facing such issue try checking both options.
// This is used in the local environment. comment this when deploying to Unix box
// File propertyFile = new File("Some.properties");
// This is used when deploying in Unix this is used.
File propertyFile = new File("/home/mr.x/secrtet/prod.path/some.properties");
Above code is self explanatory. Too good code and superb documentation 😉 .
Today Google has announced beta release of “Google web designer” – “Create engaging, interactive HTML5-based designs and motion graphics that can run on any device.” Like any other google product, webdesigner is quick to download and install. Quite amazed with the ease of installation and I have immediately started building small web page with it. But after just 10 mins I realized that this tool is not a web design tool but “Ad Designer” or you can call it as “Ad Studio”. This is not at all for developers. This is a tool for advertisement agencies to design animated ads to publish on google ads.
Google continued to be the master of simple and most user friendly design. Tool UI looks awesome and it has a light weight feel. But my excitement ended here :(. I was expecting a good tool to quickly build html pages. But its timeline , 3D drawing and color palette features are clearly suggest this is not for creating a web page which is more of contents than animating things around.
Except some simple animations, most of the animations are nothing but a match (geometrical) function. Not sure how much this tool can help developers to create animations even. Lets see what google would add to make it more web designer tool.