As a newer developer, I feel like the rush to integrate myself into the world of development comes with a lot of direct learning. I've been building a lot of concrete skills lately, and almost every problem that I've needed to solve as I've been working at Untold has required me to learn something specific about code patterns, how specific technologies work, or best practice for development. Every new bit of knowledge builds on what came before, so it all feels important at the time. It usually is important, and important very quickly, but sometimes things get left by the wayside because they aren't important right now. The problem is that they may easily become important again.
Since journeying through this attention demanding space can sometimes leave little room for reflection on what I've learned along the way, I think that actively taking the time to think about a specific project and some of the things it taught me can be a useful exercise. For me, it can help cement some of these little packets of learning in my memory, even if the next time I use them is a year from now. For the reader, I think it can be an interesting case study in learning in a field that's as diverse and rich as development, a field that I believe is made up of hundreds of little related but independent skills, as well as a whole universe of naked facts that demand interpretation.
The Project: NEAR Crossword Puzzle
Quick background on the client: The Near foundation is a nonprofit that builds and maintains a blockchain using the NEAR protocol, which has some technical differences from other blockchains in that, for instance, they support a concept of accounts. The NEAR Protocol is focused on creating a developer and user-friendly platform on which to build and explore decentralized applications called dApps which are built on this chain. Their goal is to create an ecosystem of these dApps and broadly promote communally maintained, decentralized applications and data of various types that are more resistant to monopolization. NEAR's native token is also called NEAR, and is used to pay for transaction fees and storage. NEAR tokens can also be staked by token holders who participate in achieving network consensus as transaction validators.
Purpose: The NEAR Crossword Puzzle allows a user to solve a crossword puzzle for a prize in NEAR. When I started on the project, the smart contract that checked the proposed solution and awarded the prize was already written, as was a basic frontend in React which allowed a user to submit a possible solution and sign-in to a NEAR wallet to accept the prize.
Tech Stack: The project as I interacted with it was written in React, but it also interacted with a smart contract written in Rust on the Near blockchain.
Features: The feature I built was a separate mode for the React frontend that generates a crossword puzzle based on a list of clues and answers input by the user. This crossword edit mode is accessed by a link on the app homepage and is gated to force users to sign in to a NEAR account. This is because a user that wants to add a puzzle to the chain needs a valid keypair, which every account has. Signing the transaction requires presenting a valid private key out of this keypair for proof of identity. This also allows the user to provide a bounty for solving their crossword puzzle. The user inputs a set of clues and answers, which is used to generate a puzzle. They can then review and regenerate their puzzle with a new list of clues and answers if they aren’t satisfied. Once the user is finished with their puzzle, they can send it off to the contract to be solved by someone else later on. Importantly, the puzzle creation mode allowed users who didn’t know how to interact with the smart contract directly through the NEAR command line interface tool to create puzzles.
Takeaways: Speaking broadly, the NEAR Crossword Puzzle project required me to learn about how smart contracts worked - I had no background in blockchain technologies at all, let alone programmable blockchains. I didn’t have to write the contract myself, but I did need to interact with some of its methods. For instance, this included needing to correctly structure a request to submit a new puzzle using the contract’s `new_puzzle` method. I also needed to learn about how the contract verifies the solutions of the users that try to solve it and claim the prize. The contract doesn’t keep the full array of clues and answers to check against any proposed solutions, but it does perform a specific mathematical transformation on the array of proposed answers, and it compares the result of that transformation against the puzzle on the blockchain. Before the edit puzzle mode was in place, anyone that wanted to upload a puzzle to the blockchain had to perform the same transformation on their array of answers and upload that result alongside the series of clues and the JSON object that described the layout of the puzzle. Creating a puzzle was an involved process, and the new mode for the app significantly reduced the headaches from uploading a puzzle, and made it more accessible for less technically inclined NEAR enthusiasts.
This project also posed a few challenges for me beyond just figuring out how to work remotely with the smart contract. The third party crossword layout generator we decided to use resulted in a few bugs we hadn’t anticipated. It was a little sloppily coded, and directly modified the data you put into it rather than returning a transformation of this data - this meant that if you tried to generate a crossword, then decided to change it and generate a new one within one session, you would get unpredictable results since your original data had been modified directly in an unexpected way. The solution to this involved deep cloning of a JSON object on my end, something that the layout generator probably should have done itself. It was, however, a good opportunity to learn about deep cloning in JavaScript, and therefore also come up against the concepts of copying by reference and copying by value directly, and it was also a lesson in critically examining the role of a third party dependency and understanding when it may not be functioning in the exact way you expect it to.
Finally, the project involved taking data from one third party dependency and passing to another - in this case, using the third party crossword layout generator to generate a layout in JSON and passing it to a React crossword builder to actually render it in a visually appealing way. This forced me to take the returned data from one utility and transform it into the format that another was expecting. This wasn’t particularly complicated, but it’s the sort of work that has been really useful in subsequent projects. I didn’t have a lot of experience with it beforehand, as boot camps drive home coding everything yourself. I think that working so closely with third party code is simply another programming skill, right alongside the good habits you pick up coding things from scratch, and it’s an extremely important one in modern development as well.