In this tutorial, we will see how we can integrate the Merriam Webster Thesaurus in to Spacemacs. Having a thesaurus by your side while writing, is really a productive thing. Since you don’t have to lookup every time the alternative word you want to use and that too integrating with your favorite editor is definitely a feather in your cap.
For this we are going to install an awesome package from Ag Ibragimov called mw-thesaurus.el It is originally intended for Emacs, since Spacemacs is a community driven Emacs distribution we can utilize the same for Spacemacs also.
Merriam-Webster has been America’s leading and most-trusted provider of language information, for more than 150 years, in print and now online. Each month, their Web sites offer guidance to more than 40 million visitors. In print, their publications include Merriam-Webster’s Collegiate Dictionary (among the best-selling books in American history) and newly published dictionaries for English-language learners.
In order to use Merriam Webster API it is required to register (for free) and obtain an API Key.
Register free account at Merriam-Webster’s Developer Center
First, you need to visit their website and register your application to get an api key. The registration form will look like something below. You can request up to 2 keys.
Obtain a key for Merriam-Webster Thesaurus
For our thesaurus integration we need the Collegiate Thesaurus or the Intermediate Thesaurus api key.
Once you register and obtain the keys, you can access them from your Your Account page under Your Keys section.
Set the variable
The best place in my opinion to set the api key is in dotspacemacs/user-config. Open your .spacemacs file by using <Space>fed and look for the section dotspacemacs/user-configand set the api like below.
1
(setq mw-thesaurus--api-key"YOUR-API-KEY")
Spacemacs layer
Spacemacs users can easily add the package to dotspacemacs-additional-packages and start using it, or even add it to be part of a custom layer, see an example.
1
dotspacemacs-additional-packages'(mw-thesaurus)
Commands
Once you setup the keys and added the mw-thesaurus package to your .spacemacs file. You’re ready to go. Open any text document and enable the mw-thesaurus-mode which you can access by searching using <Space><Space> in Spacemacs or M-x in Emacs.
You can see the screenshot I have taken while editing this blog post in Org-mode. In the right pane, I have opened the Merriam-Webster Thesaurus buffer.
Sometimes, the buffer won’t popup when you do a lookup, but you can get the same by searching in the buffers list [ <Space>bb ]. It will be named like Merriam-Webster Thesaurus.
Hope you enjoyed the tutorial, please share your feedback and thoughts in the comments.
In this article we will take a look at some of the guiding principles which are beneficial while working with large code base.
The whole idea of this post is to collect and come up with a checklist of significant approaches and ways to deal with large and legacy code bases.
The readers are welcome to share more tools, methods and approaches in the comments section below.
1. Onboarding Documentation
Ask if there is onboarding documentation, or someone who can give you a high-level overview of the codebase. Typically finding a person with a lot of context on the code is the fastest and most thorough way to understand the responsibilities and layouts of a codebase. Ask if they can draw an ER(Entity Relationship) diagram, it’s extremely valuable documentation for any additional developers.
Show me your flowcharts and conceal your tables, and I shall continue to be mystified.
Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.
— Fred Brooks
2. Read Documentation
Read all the documentation possible, especially design documentation. This should hopefully give you some clues as to both function (what) and purpose (why). The discussion around this will also introduce you to the major players in the architecture of the codebase.
Documentation is the castor oil of programming.
— Gerald Weinberg, The Psychology of Computer Programming
Note this does not necessarily mean formalized design docs, it could just be searching for any README’s or relevant wiki pages. You’re just gathering threads at this point, and documentation tends to be a lot more compact and easily digestible than foreign code.
3. Look at the models
Look at the models – there will be compact representations of data at some point. This gives good insight into the shared language of the code and can give a lot of clues about how things are done. They also tend to be a lot more human-readable than other pieces of code, so this is a plus.
The architectural model provides a Gestalt view of the system, allowing the developer to examine it as a whole.
— Scott Ambler, Agile Modeling
4. Find and Skim the largest files.
Typically these files perform the majority of the work, have the most responsibility, and introduce most bugs. Knowing roughly where the major players are and what they do makes it a lot easier to read any individual file.
You need to be fully aware of the presence of any God Class or components in your codebase which pose a serious threat to the long-term health of your product.
5. Run the application
Run the application, find some small behavior (a single, simple endpoint) and debug it. Step through the application code so you can see how a particular request flows through the system. This can show you how a lot of different concerns within the code are tied together and also ensures that you’re set up for both running and debugging the codebase.
6. Don’t plan a full rewrite
Don’t plan or do a full rewrite – it’ll almost never work. Jeremy Burton has this wonderful postdiscussing the social and economical impacts of code re-writes.
When you inevitably come across a trade off, choose the one which is easiest to change later. Everything else is just noise. Large changes in legacy systems often suffer from the second system effect among other problems.
7. Learn the tools
Learn and use tools to automate the build system and quality assurance (Jenkins, Sonarqube,Docker, Git, etc.)
Great tools let us do the impractical and the impossible. They give us super powers. The goal should be to know your tools so well that you can focus on the work at hand, without having to think — they should be second nature.
8. Sharpen the saw
Sharpen the Saw means preserving and enhancing the greatest asset you have–you. It means having a balanced program for self-renewal. It is the mindset to seek continuous improvement and renew yourself professionally.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
— Abraham Lincoln
Take the time to improve your skills and the skills of your team (coding dojos, experiments). An excuse to not sharpen the saw is an excuse for failure, burnout, and mediocrity.
9. Spend time with your end users/customers
If possible spend time with the main user / product owner (especially in peak periods). You’re blessed to have users, who understand your system.
The team is actively encouraged to spend time with actual customers to learn more about their needs. A developer may spend time observing real users and come away with brilliant insight into what is most needed.
10. Focus on cross cutting concerns
The crosscutting concern also known as system-wide concern is a concern which is applicable throughout the application and it affects the entire application. These are the concerns representing functionalities for secondary requirements. These are typically implementation details that need to be kept separate from business logic. Do refactoring and first focus on cross cutting concerns (APIs, translations, caching, logging, database, etc.)
11. Migrations
Migrate things to well tested isolated APIs (e.g. use REST / Graphql APIs with new endpoints in the frontend and try not to use untested code for these APIs). It is always a good idea to have a strategic plan for migrations in your development roadmap. It could be every 6 weeks or 6 months, but it should be done at regular intervals of time or else you will be incurring a large amount of tech debt in your codebase.
12. Move fast and break things
Don’t be too backwards compatible (move fast and break things) This way of working usually emphasizes testing out new ideas, iterating quickly based on data, and aiming for more frequent points of learning. Allen Yang exhaustively discusses the pros and cons of this approach in this Forbes article.
13. Get the team on board
If there are multiple people you need their buy-in and support for whatever approaches you want to do
14. Plan for “health by a thousand small improvements”
It will be an iterative approach and you will refactor as you go.
15. Don’t assume different = bad
People might have done differently, consider using their approaches. You might do it differently. But it’s better if you keep a consistency within the codebase. In codebase management consistency trumps cleverness.
16. Create space
Consider introducing a Fix-it Friday where everyone can work on little improvements. Think about conducting a bug-bash in your organization, at regular intervals of time so that it automatically creates a platform where all the developers, testers, program managers, usability researchers, designers, put aside their regular day-to-day duties and “pound on the product”.
Because each person will use the product in slightly different (or very different) ways, and the product is getting a great deal of use in a short amount of time, this approach may reveal bugs relatively quickly.
17. Create a Non-Blame culture
Stuff will break if people risk improving things. Avoid blame shifted to them. If bug trackers ping individual people consider pinging the whole team instead.
If you get your ego in your way, you will only look to other people and circumstances to blame.
Jocko Willink
18. Consider automation
While “development automation” is not a commonly used and recognized term of the software development industry, business people normally use it to refer to “anything that can speed up the development process and allow the organisation to bypass most, if not all, of the software development process, jumping from a simple business-level wish list to a ready-for-the-market product (writing as little code as possible and hiring as little programmers as possible)”.
Any technology/methodology that can reduce software development to the most complicated thing the average business guy can understand.
Here are some examples of development automation:
Automatic update of dependencies
Automatic build process
Automatic checking of style rules
Automatic execution of unit tests with every build
Automatic update of code-generated proxies
Automatic creation of deployment packages
Automatic configuration of target environments
Automatic deployment to development or QA environments
Automatic computation of metrics, such as Code Coverage
Automatic smoke tests
Automatic generation of release notes, or at least of the bug list that goes in the “Fixed in this build” section
19. Start with the tests
This one is the most annoying, but worth doing. Whenever you improve a feature a bit try adding a test. Often in legacy apps there are no good tests. A lot of people recommend writing a test suite for the whole app before you do anything. If you are lucky enough to do this try it. The iterative approach more realistic as you can also do feature work while refactoring.
When doing tests focus on integration (vertical/functional/etc) and not unit tests (unless the “unit” contains critical or complex logic). Your goal is to know “that you broke something” – you get by if you don’t always know “what you broke“.
Write automated tests (unit, integration, acceptance) for existing code where ever possible. Write at least unit tests and integration tests for new code.
Make sure you have development and test environment available, including data transfer from production to test.
20. Acknowledge tech debt
Not everything needs refactoring. If it’s not critical and nobody needs to touch it consider acknowledging it as tech debt. Add larger notes above the problematic areas and explain why you aren’t refactoring it, explain things worth knowing to understand the code better, etc. Whenever you leave comments remember that comments should explain “why” not “what” the code does.
21. Read a lot of code
Spend time reading code in the codebase even if it does not seem to make sense, even if you don’t think you’ll need to know that part of the code. Keep reading until it starts to make sense. The trick is to just read. You can even avoid tools that automatically navigate the code because you will know eventually where things are.
22. Debugger is your BFF
The first and the foremost task while working with existing code bases is you need to get debugger working. Nothing can explain the processing workflow better than tracing the execution.
Get familiar with your debugger. You may be surprised by how deep in a call stack a bug can live. It will also make you intimate with the different ways your codebase is orchestrated together. Also having any kind of schemas, protocol definitions and tests can help grasp whats happening in the system.
23. Use the boyscout approach
Clean where other left dirty stuff. Sure, many here would argue that “never touch a running system” is a gold rule, but what if the running system is running in the wrong way?
The Boyscout rule
Always leave the campground cleaner than you found it.
If everyone attain her/himself to this rule, there wouldn’t be what we call innovation.
24. Don’t try to fix the pile of mud
Complicated software are infections of a complicated business requirements. When something is a pile of mud, don’t try to fix the mud.
Fix the business requirements until it get easier to handle. This also leads, most of the time, to a massive reduction in messy code bases.
At this point you should have a fairly solid understanding of at least the most critical points of the codebase, and also be set up to run and debug it. You should also have at least one or two points of contact to ask questions. This gives you a good framework for figuring out how to modify the codebase moving forward.
Software craftsmanship is an approach to software development that emphasizes the coding skills of the software developers themselves. It is a response by software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability.
In this article we will take a look at different perspectives about craftsmanship in general and some specific notions of the same in software and programming from various authors and programmers.
The Craftsmen’s Creed
In the Pragmatic Programmer, Andy Hunt and Dave Thomas discusses about craftsmanship with the likes of construction workers and civil engineers on how they treat their craft by envisioning it as a divine endeavor of building cathedrals.
The construction of software should be an engineering discipline. However, this doesn’t preclude individual craftsmanship. Think about the large cathedrals built in Europe during the Middle Ages. Each took thousands of person-years of effort, spread over many decades. Lessons learned were passed down to the next set of builders, who advanced the state of structural engineering with their accomplishments. But the carpenters, stonecutters, carvers, and glass workers were all craftspeople, interpreting the engineering requirements to produce a whole that transcended the purely mechanical side of the construction. It was their belief in their individual contributions that sustained the projects:
We who cut mere stones must always be envisioning cathedrals.
—Quarry worker’s creed
Within the overall structure of a project there is always room for individuality and craftsmanship. This is particularly true given the current state of software engineering. One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today’s civil engineers, while our craftsmanship will still be honored.
Gaining Mastery
In Software Craftsmanship, Pete McBreen puts emphasis on attaining mastery over one’s craft.
Craftsmanship is about gaining mastery. Yes, a person can learn to perform a subset of the tasks in a relatively short time, but developing complete mastery does not happen quickly.
The road to mastery is not lined up with daisies and spanned by a rainbow. Mastery hurts. In Drive, Daniel Pink discusses about the unique characteristics about Mastery like mindset, pain and asymptote.
A related idea is that one practices a craft and that as soon a person stops practicing, her mastery fades. Hence beginners are apprenticed to a craft, because people cannot afford to take time away from their craft to teach others.
In traditional crafts, apprenticeship is situated learning, where the apprentice takes over the easy, mundane tasks and then absorbs through observation and supervised practice the tacit knowledge necessary to perform the more esoteric, arcane tasks. Each apprentice trains a successor so that he can move on to more advanced tasks. In this manner, the master craftsman has to be concerned only with teaching the most advanced skills and can focus attention on productive work.
The Essential Elements of Craftsmanship
In Clean Code, Robert C Martin enlists the essential elements that makes up the craftsmanship. There are two parts to learning craftsmanship: knowledge and work.
You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing.
The Craftsmanship Mindset
A true craftsman need to have a proper growth mindset not the fixed mindset, as Carol Dweckdiscusses about the two types of mindsets more prevalent among people, in her seminal book named Mindset.
In the Clean Coder, Robert C Martin takes a different approach by advising us to take the right mindset to craftsmanship.
The word craftsman brings to mind skill and quality. It evokes experience and competence. A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes. A craftsman is a professional.
Craftsmanship is the mindset held by craftsmen. Craftsmanship is a meme that contains values, disciplines, techniques, attitudes, and answers. But how do craftsmen adopt this meme? How do they attain this mindset? The craftsmanship meme is handed from one person to another. It is taught by elders to the young. It is exchanged between peers. It is observed and relearned, as elders observe the young. Craftsmanship is a contagion, a kind of mental virus. You catch it by observing others and allowing the meme to take hold.
CONVINCING PEOPLE
You can’t convince people to be craftsmen. You can’t convince them to accept the craftsmanship meme. Arguments are ineffective. Data is inconsequential. Case studies mean nothing. The acceptance of a meme is not so much a rational decision as an emotional one. This is a very human thing. So how do you get people to adopt the craftsmanship meme? Remember that a meme is contagious, but only if it can be observed. So you make the meme observable. You act as a role model. You become a craftsman first, and let your craftsmanship show. Then just let the meme do the rest of the work.
The 3 dimensions
In the book, The Craftsman, Richard Sennett explores the dimensions of skill, commitment, and judgment in a particular way. It focuses on the intimate connection between hand and head. Every good craftsman conducts a dialogue between concrete practices and thinking; this dialogue evolves into sustaining habits, and these habits establish a rhythm between problem solving and problem finding.
A few days ago, Tom Dale opened the Ember 2018 Roadmap RFC that set the goals for Ember in 2018. The RFC consisted of three major goals like:
Improve communication and streamline decision-making, and empower new leaders.
Finish the major initiatives that have already been started.
Ship a new edition, Ember Octane, focused on performance and productivity.
In this article we will focus on Ember Octane which is primarily targeted to improve performance of Ember applications for low-end devices and the like.
Ember Octane will be a new edition of Ember, emphasizing its modern productivity and performance. The Core team promises to polish Ember’s compatibility with new JavaScript language features like native classes, decorators, and async functions. There is also some significant emphasis to continue efforts like optional jQuery and treeshaking that reduce file size. It is also expected that the Ember team will overhaul the Ember homepage to align with Octane and tell the story of modern Ember.
Some of the primary motivations for Ember Octane came from The 2018 Community Survey, #EmberJS2018 blog posts, Ember Discussion Forum and deliberations among the Ember core teams.
The homepage looks a bit outdated and does not a very compelling job at selling Ember to new users, IMHO. This needs to change.
Ember’s custom object model isn’t hard to learn, but it’s a big reason people are turned off before learning why Ember is such a great choce. I’d like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators.
ES6 syntax, the new file layout, new templating etc. — the new features will land in 3.x releases as non-breaking changes, but let’s prepare to show off the sum of all those amazing parts. Sell the vision, right now! A ‘relaunch’ of Ember in the minds of those who dismiss it.
Ember releases a new, stable version every six weeks. For existing users, this reverberation of incremental improvement is easier to keep up with than splashy, big-bang releases.
However, for people not following Ember closely, it’s easy to miss the significant improvements that happen over time. As detailed in the forthcoming Ember Editions RFC (being worked on by Dave Wasmer), every year or so the team will release a new edition of the Ember, focused on a particular theme. The set of improvements related to that theme, taken together, mark a meaningful change to how people should think about Ember.
In 2018, the Ember team will release the first edition of Ember, called Ember Octane. Octane will focus on the themes of productivity and performance. Ember Octane will generally highlight how Ember excels in performance-constrained environments, particularly on mobile devices, as well as the productivity benefits of modern JavaScript features like classes, decorators, and asyncfunctions when paired with Ember’s strong conventions and community.
We can also expect the team to review the new application blueprint, to ensure that it is up-to-date with the latest Ember Octane idioms and includes the right set of addons to help new users achieve our goals of productivity and performance.
Ember Octane is about doing more with less. Not only does this make Ember simpler to learn, it makes the framework smaller and faster, too.
These are some of the highlights of Ember Octane as quoted by Tom Dale in the RFC:
1. No jQuery
Currently available as an optional feature, this will be enabled by default. The process of making jQuery optional started with the Make jQuery optional RFC by Robert Jackson in January this year. For the past Ember has been relying and depending on jQuery. This RFC proposes making jQuery optional and having a well defined way for users to opt-out of bundling jQuery.
Mathias Bynens has demonstrated the major drawback of having jQuery, the increased bundle size, which amounts to ~29KB (minified and gzipped).
2. Svelte builds
“svelte” builds of Ember, are where deprecated but unused code paths in the framework are removed during an application build. The team will get more aggressive about deprecating code that is not widely used. With the eventual introduction of Svelte builds, there will be a mechanism to say “strip out any code for deprecated features from 2.0 to 2.8”.
There is an issue in the official github repository regarding svelte builds with the title [Project Svelte] Deprecation Introduction Hitlist opened by Chad Hietala which highlights some of the ways and approaches to find deprecations and the list of deprecation IDs.
Some preliminary explorations on svelte builds have also taken place among Ember developers some of which can be found in this thread in the Ember Discussion Forum.
You can find some references to svelte builds in this official blog post by Matthew Beale on The Road to Ember 3.0.
3. Native JavaScript classes
Ember Octane will make use of native Javascript classes which perform better and require less code, and integrate better with tools like TypeScript and ESLint.
4. Glimmer Components
Glimmer is one of the fastest DOM rendering engines, delivering exceptional performance for initial renders as well as updates. Architected like a virtual machine (VM), Glimmer compiles your templates into low-level code so it can run as fast as possible—without sacrificing ease of use. With Ember Octane, Glimmer components offer a greatly simplified API and remove common slow paths.
Glimmer differentiates between static and dynamic components, thus reducing the number of elements that need to be checked when looking for changes. This differentiation can be achieved thanks to the expressiveness of Handlerbar’s templates.
Another key difference between Glimmer and other solutions lies in the way nodes are stored and compared. Glimmer stores nodes as simple stream-like objects (that is, simple queues of values) rather than full-fledged DOM-like nodes. To find out whether a real DOM node needs updating, the final value of a Glimmer node is compared to the last known real DOM value. If the value has not changed, no further actions are taken.
5. Incremental rendering and rehydration
Incremental rendering addresses problems like, to get high levels of animation performance you have to synchronize the DOM (tween stack across the entirety of the animation chain in order to minimize layout thrashing) and skipping style updating when updates would be visually imperceptible.
In React, Fiber takes charge of solving problems like it. Bringing a feature named “incremental rendering” which split rendering work into chunks and spread it out over multiple frames. The new rendering logic allows a better approximation of the principles of an animation.
In traditional way React uses Stack, which is synchronous and recursive. But can’t be split in chunks, have a heavyweight context and other issues. The goal of React Fiber is to increase its suitability for areas like animation, layout, and gestures. Other key features include the ability to pause, abort, or reuse work as new updates come in; the ability to assign priority to different types of updates; and new concurrency primitives.
Incremental rendering: the ability to split rendering work into chunks and spread it out over multiple frames.
Rehydration in the context of isomorphic JavaScript applications is the act of regenerating the state that was used to render the page response on the server. This could include instantiating controller and view objects, and creating an object or objects (e.g., models or POJOs) from the JSON that represents the data used to render the page. It could also include instantiating other objects, depending on your application architecture.
Rehydration is more common in frameworks like React where SSR is given an important consideration and with the advent of Ember Fastboot, the concept of rehydration is also becoming a buzzword in the framework arena.
6. Treeshaking
In computing, tree shaking is a dead code elimination technique that is applied when optimizing code written in ECMAScript dialects like Dart, JavaScript, or TypeScript into a single bundle that is loaded by a web browser. Rather than eliminating code that can never be executed, tree shaking starts from entry point and includes only the code that can ever be executed. It is succinctly described as “live code inclusion”.
In Ember, tree shaking has already been part of the JavaScript Module API RFC which was implemented in the recent versions of Ember.
To get deep insights about tree shaking, please read this article by Rich Harris, one of the contributors of Rollup giving a detailed explanation of how tree shaking is done in Rollup.
7. Eliminating the runloop
Ember Octane will also focus on eliminating the runloop from the programming model, replaced by async and await in tests.
Timeline
The final timeline and feature set of Ember Octane will be determined by the Core team and are not set in stone.
Ember Octane will mostly incorporate all features that are either finished or being implemented now, keeping with the commitment to finishing what has been started by the Ember Team. It is recommended that the team will not plan for Octane to have any features that are not already close to being done today, so that they have adequate time to make sure they all work well together as part a cohesive programming model.
The process of releasing a new edition also gives the developers and users an opportunity to evaluate what it’s like to use Ember end-to-end. It is highly likely that the team will overhaul the Ember homepage, focusing on Ember Octane and how it helps solve targeted use cases.
The Ember Team will perform a holistic review of the guides, making sure that examples use the latest idioms and set new learners on a good path.
