TL;DR:

Apple announced their AI system, Apple Intelligence, at WWDC. As an Android user and a Google services user, I’m intrigued by Apple’s focus on privacy but prefers my Pixel due to habit. While Google’s AI might be better, their ad-based model raises privacy concerns. Apple’s hardware focus and privacy emphasis might be a better fit in the future, but switching to iPhone requires a whole ecosystem shift.

Apple WWDC 2024 launched with a slew of Apple Intelligence — Apple’s own AI brand! — that work tightly with Apple’s echo systems and service.

I’ve had a lot of thoughts, but Dave 2D on youtube echoed similar sentiments and trains of thought that I have, and I thought I’d try to put them into words here.

In his video, Dave said the company behind your phone’s operating system will likely win the AI race. I agree, at least until something totally new comes along for phones. This isn’t going to change anytime soon.

I’m not an iPhone user, I only use my work iPhone for work. I did use it exclusively when my Android phone died a few years back, but I still prefer Google Pixels over an iPhone just because I’m more used to Google’s operating systems.

I’m lucky that I live in the UK, so the iMessage drama doesn’t impact me in the slightest. My family and I use WhatsApp and it works well.

Overall, I use Google services more. I even have Google One for my Nest cameras and more Google Drive storage.

However, looking overall at Google, their main business focus is Ads. When you combine that with whatever AI offering they’re going to put on the table, you have to feel worried. Even if Google’s AI functionality is better, it’s because my data is likely used to fuel ad campaigns for other companies thriving on Google Ads.

On the other hand, Apple’s main business focus is selling hardware, and they don’t care as much about selling Ads — correct me if I’m wrong — . In their keynote, they’ve put a lot of emphasis on AI privacy and even went the extra mile to notify you every time you interact with ChatGPT. This level of commitment and openness may allow you to use your iPhone with Gemini in the future — if Apple decides it, that is — if you really want to use Google’s Gemini over ChatGPT.

However, switching to an iPhone involves more than just purchasing a new phone, as the ecosystem kind of forces you towards additional purchases to “complement” your iPhone, but it is definetly a strong option.

It’s an interesting time to be alive, and the competition is only going to get fiercer as time goes by.

Google vs Apple — Which AI to choose! was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

• “Why are we running?”
• “Because…um…we need to”
• “Why?”
• “Because we don’t want to be late”
• “Why can’t we be late?”
• “Because it is not a good thing to be, I don’t like being late.”
• “But you didn’t do anything wrong!”
• “…”

A conversation with my son.

38th birthday was the day I felt, truly felt it. It hit me like a cold water on the winter, it suffocated and crushed my soul like a nut by a nutcracker, I could no longer breathe, and I lost the will and the drive for, well everything!

I stopped running. My lungs burned, but it was the hollowness inside that made me stumble to a halt. I’ve always cringed when people say that being old is a mindset, they were right. I didn’t feel it when I was 30 nor did it wait for me to hit 40, nope, 38 was the year I truly felt ancient.

For the past five years, I’ve been running. Just living as a sideline character, reacting but not truly acting. It caught up with me when I stopped. Five years of running drained my energy and left me feeling exhausted, my legs spasmed uncontrollably.

For a week, I hunkered down, weathering the self-inflicted storm of doubt and loathing. A cold, sucking feeling drained the colour from my world, leaving everything muted and meaningless, urging me to find purpose, an anchor in the swirling chaos. So, I took a step back, a deep breath, and began rebuilding. As a software engineer, my comfort zone had been logic, the clean lines of code. I knew I would find solace in a new project, a fledgling flame to reignite the embers of my passion. But warmth alone wouldn’t conquer the biting economic winds. My finances, already shaky from neglect, shuddered under the strain of the economical inflation rise. Action was imperative. I needed to shore up my crumbling foundation, brick by solid brick, forging a resilient fortress against future financial turmoils.

My gnawing unease demanded action, but I wouldn’t settle for anything mediocre. I craved genuine passion, something that fuelled me and brought value to others. So, I took a step back, brainstorming possibilities for sometime. I envisioned hobbies that brought joy, alongside income streams that could ease financial burdens and secure our well-being. It was a slow, careful process, but I was determined to enjoy it as much as I could.

While waiting for my side project idea to simmer, I tackled my finances head-on, slashing unnecessary costs that offered little to no joy. While the savings weren’t as significant as I’d hoped, the process itself was empowering. For the first time in a long while, I felt in control, like I was actively building a brighter financial future for myself and my family. This brought a sense of hope and resilience I hadn’t felt in years.

At first, I couldn’t grasp my wife’s urge to move furniture and shift the bed around. But seeing the living room through fresh eyes, the sunlight bathing new corners, brought it all home. It is fine to seek change for its own sake. We do need occasional jolts to truly appreciate what we have, to slow down and admire the life we’ve built together. Maybe some wrinkles have appeared, but that just adds character to an old fella who’s still learning to savour the moments.

— Amr

Feeling old was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

tl;dr You can enjoy both listening and reading without having to sacrifice either, if you want to take a look of my experience starting at listening and ending at doing both continue reading. Or you can go straight to the Lessons Learned section and know that listening and reading are not mutually exclusive. Enjoy what makes sense and is more comfortable for you!

Listening is not the same as reading!

Listening is not the same as reading, but really who cares!

There is always this debate going on between two groups of people. People who cherish reading physical hard/soft copy books, and those who choose to use other digital media to consume book’s content, whether it is reading from a kindle or using audiobooks or other methods.

This debate, in my opinion, is meaningless and counterproductive, that’s why I wanted to get it out of the way as the first part of this article to say that whatever suits you go for it. In my opinion, there is no right or wrong way to consume a book. If a person doesn’t have time to sit and read, then other consumption methods are a good use of time, but if someone enjoys the physical sensation that accompanies carrying a book, then they should embrace it.

I’m proud of my journey that started back at the beginning of 2017 when I decided to purchase an Audible subscription, and I consider this subscription the best investment I’ve made for myself in the last 10 years — I know I should be more embarrassed about this! — and until now, I’m still enjoying listening to books on my walks.

Listening to books was handy plenty of times as I can get motion sickness on car/boat/train/plane trips, but audiobooks keep me occupied into the book’s world for the entirety of those long trips!

I can understand the argument that says the author intended for the book to be imagined by the reader and the execution of the narrator can mess it up. Not to mention that some books — mostly non-fictional books — have diagrams/figures that would require a reader, not a listener. But then there are audiobooks like Sherlock Holmes narrated by the fantastic Stephen Fry that can outperform the Sherlock Holmes BBC show by a vast distance!
I can understand both arguments, and I appreciate both of them.

However, I’m still going to enjoy that book for what it is regardless of the medium of consumption.

With that debate out of the way, if you want to make a habit of consuming books as maybe one of the new year resolution, I believe listening can be a great introduction into this magnificent world. By the end of the year — no promises! — you should appreciate both listening and also reading and maybe even become more like me enjoy doing both at the same time!

Getting started with your listening experience

Before we start talking about starting your experience, one golden rule you should always follow: NEVER listen — or read for that matter — to a book that you don’t like!
The main point is to lose yourself to the world the author created for you, to get entangled with its characters and emotionally advance as events progress within the book.
If you are engaging with a book because you have to then nothing I’m going to discuss here is going to make any lasting effect, just be aware of that!

1st thing you want to do is to choose a subscription plan. It is a commitment, so make sure you — cough — commit to it!
Make sure it has books you like, browse its catalogue before making your decision.

2nd you should select at least 3 to 5 books you want to start straight away (put them in your wishlist if that feature exist). In 2017 I completed my goal to finish 12 books a year, which is entirely feasible, and if you can choose the 12 books you like from the get-go, go for it, but I’m quite sure plans will change midway!

3rd you need to dedicate a commute to your book. A daily commute would be best. Listen the whole time in this commute, and make an effort to focus on the listening without drifting in thoughts.

4th optionally make excuses to commute more. To finish that chapter, or to know how the main character narrowly escaped, or how the villain controlled the dragon!
Capitalise on the urge of wanting to listen more and don’t quill it, embrace it!

My journey and how I ended up reading again!

When I started listening, my goal was simple, develop a reading habit so that I would always have something to occupy my time in a meaningful way. I got frustrated amidst failing to commit, and on a whim, I decided to purchase an Audible subscription plan that had a good deal for three months.

I purchased the same audiobook that I was trying — and failing — to read at the time: Algorithms to live by; it was not a great experience to listen!
Don’t get me wrong, the book itself was great, but if I started this journey all over again, I would begin it differently!

The reason being that non-fictional books can be quite tricky to follow without drifting in thoughts, especially if you’re starting your listening experience since the narrator usually have a monotone voice that can get boring quite quickly. Non-fictional books typically focus on the added-value — generally in the shape of advice — rather than the story and its narrative, not to mention that there are no characters to be invested in, which makes it a horrible first-time listening experience!

Thankfully I had quite a long commute, and I was bored with my music library, so I kept on it until I managed to give ~90% of my attention to my audiobook.

Even though I wouldn’t recommend starting with non-fictional books, I’m thankful for the time I spent on it, which taught me a lot and took a little over a year to shape up. However, I ended up finishing a total of 14 books by the end of February 2018.

Then my real enjoyment began with 1984 by George Orwell and the fantastic Andrew Wincott as a narrator!

It was like wandering in the sand for so long that you thought everything is a shade of yellow until you see a colourful forest with its deep green and multicoloured birds flying and singing!

From that point on, I upgraded my subscription to three credits per month. I started consuming a lot of fictional books, including sagas like Pierce Brown’s Red Rising and trilogies like Chronicle of the Unhewn Throne by Brian Stavely among many more. Up until recently, when I switched back to one credit to give me some time for my reading endeavour along with my listening with 60 books finished in my Audible library!

During 2017 towards the end, I started to realise that I achieved my goal when I began criticising books without really hating it, and when I was looking forward to 15th of the month when I get my credit to choose a new book!

Criticising a book was a massive milestone for me, as when I started consuming books, I was like a child, happy with whatever sweets I eat. To be able to criticise is to have the maturity to compare and dissect content and come up with counter-arguments and alternative scenarios, and that is just a wonderful feeling!

In August of 2019, I started reading again, and it felt like all the listening time has added something, books had taken a different shape in my head than when I started in 2017, and my love for books has taken a new turn for the better.

The reason I turned back to reading was simple. I wanted to enjoy my non-fictional books again without leaving my colourful forest!
I thought I would rather experience them with reading while focusing my listening experience on fictional novels, and this way, I can keep on reading without sacrificing my listening time!

The decision was easy as my commute was combining transporting by a slow train, a good time for a book without motion sickness, and then a lengthy walk to work, an excellent time for listening, and with that the two-books strategy was born!
So far, I’ve read around five books of different sizes, and I found myself sneaking some time to go to a coffee shop to steal more reading time, which is exciting.

Lessons learned

The journey turned into a habit, and for the last few months, I kept thinking about what I learned from it and how I can help others going through the same. Below are some of the lessons I accumulated from my mistakes and my accomplishments throughout my journey.

Suggestions for choosing a new book to listen to

If you don’t have any books in mind, here are some tips that helped me when choosing a new book to listen to:

1. Search books in the genre you like, I would suggest going for fictional genres if you’re getting started.
2. Check smaller books first, don’t go for the big 30+ hours books, it can get overwhelming. A good starting range would be between 4 to 13 hours long.
3. Listen carefully to the book’s sample and its narrator’s performance, preferably on the device and headphones you’re going to use in your commute. Make sure you’re comfortable with it.
4. Check the rating but don’t read into it too much! A good rule of thumb: if a book has 4+ stars with more than 1k+ reviews, you probably going to have a great experience!
5. Start with stand-alone fictions, and slowly move into big trilogies and sagas, seeing the story’s ending is remarkably satisfactory.

Tips for focusing on listening

If you always drift in thought or itch to check your mobile every 5 seconds, here are some pointers that I learned to develop, which helped me focus on listening, even when listening to non-fictional books!

1. Don’t stress it. It can take time, but it will come naturally. Just don’t stress about it too much. Trust me on this one.
2. Maintain a loose focus; a sharp focus can and will be tiring in the long run.
3. Put your phone in your pocket at all times!
4. Use a wireless headset for the best experience and less entanglement.
5. Put your phone on silent mode without vibration. If you have to read something on your mobile, pause your listening before doing so.
6. If you want to take notes, stop the audiobook first.
7. Treat it like reading and give it your full attention without losing your surroundings.

Taking it a step further

The strategy of reading and listening at the same time is good enough for the time being. Still, I’m already foreseeing a problem with long-running series, how can I refresh my memory of what happened in the last n books before reading the n+1's!

My work in progress solution would be to incorporate writing into my strategy and start to have a recap with some template so that I can remember the story’s events, characters and their relationships. Then I can just skim through it within a few hours to get back on track whenever a series adds a new book!

The reason I think writing something myself is better than going to Wikipedia or Reddit for reference is that writing adds another level of intimacy between me and the book, and increase the critique mental model that I love so much.

In conclusion

Making a habit of reading books is a worthy goal, and if you’re struggling to get started like I was, I hope you found my journey insightful and the Lessons learned helpful. I’m also hopeful that you can see that the consumption method of a book is less important than the book’s content. That is what truly matters!

If you liked this article, consider following me for more. If you loved it, then don’t forget to click on the green hands right below this text. 👏👏👏

Also, follow me on Twitter!

How listening to books made me a better reader without giving up listening! was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been quite busy lately and currently preparing for my presentation @agiletourlondon which takes place on October 19th, so if you want to meet me in person and you happen to be in London, come to say Hi :)

The session is about the use of Gamification elements into an Agile process, and how would that can make a fun and enjoyable environment for the whole team.

This topic is quite close to my heart as it combines Agility, Gamification and software engineering & craftsmanship.

This session will also debut my Progression-Driven Development (PDD) Framework, and I will follow up with more details in this blog about the framework after the 19th of October.

PS: I have a discount code SAG15 for 15% at checkout if you want!

If you liked this article, consider following me for more. If you loved it, then don’t forget to click on the green hands right below this text. 👏👏👏

Also, follow me on Twitter!

Gamification & Progression-Driven Development — Agile Tour London 2018 was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m writing this post to give a heads-up about a UK-wide Java competition, for professionals and students, that’s happening right now.

The Java Challenge UK is a gamified online challenge, running over six weeks.
It works like this: you get 15 minutes to answer a maximum of 17 multiple-choice questions. If you run into trouble, you get three “jokers”, giving you a 50/50 chance of picking the right answer, you can choose to see what the other contestants answered, or you get to call a friend to help you out!

So, it’s a fun chance to test your skills and to compete against other Java lovers to become the champion. What’s also fun, though, is that you get the chance to fight for some quality prizes; the first prize, for example, is a £800 flight voucher, valid on over 300 different airlines

You can enter the challenge, and get more information on the awards and rules, on the official challenge page.

If you liked this article, consider following me for more. If you loved it, then don’t forget to click on the green hands right below this text. 👏👏👏

Also, follow me on Twitter!

Java Challenge UK: a gamified challenge for Java students and professionals was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous post, we built the application structure for our solidity code. In this article, we are going to develop our smart-contract (business logic) for the Survey DApp.

Table of content

This series is separated into 3 sections:

1. The smart-contract — Create the Survey smart-contract (You’re here)
   1.1. From Idea to a business plan
   1.2. Setting up development environment with Truffle
   1.3. Creating the smart-contract the TDD way — You’re here
   1.4. Testing Solidity Code on TestRPC, Local Ethereum chain and Testnet
2. The Backend — Server side Ethereum development
3. The Frontend — Client side user interface and wallet integration

Incremental updates the TDD way

I’m a big fan when it comes to TDD and BDD, and one thing that TDD does best is to minimise the process of thinking about your code and approach the source code in a more functional approach.

BDD is using the same concepts as TDD but communicates it using examples instead; for example:

“Given that I’m a [ROLE]
When I [CONDITION]
Then [RESULT]”

In this article you will see the above format used for clarity purposes.

We can also create Solidity Mocks, but it will not allow certain test cases to be executed since we cannot control the msg.sender and the msg.value variables, so I will preferably work with Truffle’s Mocha test suits.

We are going to extend Mocha test suit and use it with ChaiJS to make a better quality code for my contract.

I also included ChaiJS and some of its plugins as part of my dependencies using npm install --save-dev chai chai-as-promised chai-bignumber

Creating the Contracts Shell

The first thing we need to create is the shell for our smart-contract, in this Simple DApp, we only need to create two solidity contracts.

1. SurveyFactory.sol — The solidity contract that creates the survey to keep track of the survey’s owner and optionally charge fees from Survey Makers to run the service.
2. Survey.sol — The solidity contract that works with the survey itself like adding participants, removing participants, finishing survey and more.

In the contracts folder, create two files SurveyFactory.sol and Survey.sol and write the minimal code for a valid solidity contract, such as:

pragma solidity ^0.4.19;

/// @title SurveyFactory — Creates surveys and charge users
/// @author {YOUR NAME HERE}— <{YOUR EMAIL HERE}>
contract SurveyFactory {
 //Just a shell...for now!

}

And do the exact same thing for Survey.sol as well.

pragma solidity ^0.4.19;

/// @title Survey — Work with a Survey to add participants finish survey 
/// @author {YOUR NAME HERE}— <{YOUR EMAIL HERE}>
contract Survey{
 //Just a shell...for now!

}

If you installed Truffle globally, you can create the contracts by simply running the command truffle create contract SurveyFactory and truffle create contract Survey. However, you will have to change the default solidity compiler version.

Creating the Test Suits

Now we need to create the same for our tests, we need to have two test suits, one for SurveyFactory and the other for Survey.

In the test folder, create two files survey_factory.js and survey.js and write the minimal code for a valid solidity contract, such as:

If you installed Truffle globally, you can create test files by simply running the command truffle create test SurveyFactory and truffle create test Survey. This will create the same identical files.

Preparing the test suits

Before we start with the test cases, we need to figure out how we want to work with specific common variables and patterns throughout your test cases; it is usually a good practice to separate those in helper classes and make yourself DRY from the beginning.

Error Helpers

The first helper is to work with Solidity errors. Since the most common exception is going to appear from a require statement, then we need to figure out a way in which we can detect that. Luckily Solidity throws the code “revert” to that error, and we can try to see if the error contains the “revert” keyword or it is a different error.

This helper is using the same concepts as the assertRevert.js from zeppelin-solidity library.

Create a folder inside the test directory named helpers and add the following file inside of it.

Packages and Common Variables helper

Another essential helper is to group all the variables that we think is going to be utilised by our test cases together so that we DRY.

We first need to think about the Survey DApp roles; we have three roles in our DApp:

1. Survey DApp Owner
2. Survey Maker
3. Participants

It makes sense to create variables for these accounts, also set other shared variables, for example, the Survey DApp Creation Fee or different constants.

Inside helpers directory, add the following file :

With that in mind, we can go back to our test files survey_factory.js and survey.js and use the helpers we created, it should looks something similar to the following:

Note that I did repeat some code twice (initialization code), that is for readability purposes, and ease of access!

Now, we first need to run ganache-cli, just execute npm run testrpc in a command-line and open a new command line to prepare for testing.

With the above, we are ready to work on our test cases and start coding some solidity.

Starting the TDD Cycle

1 Adding Test Case(s) — Adding the test case(s) by creating a logical group using describe and add various test case examples underneath it, for example, we need to cover test cases for “Create Survey” functionality, so we can build our test cases to cover all examples of this requirements. Such as:

Example #1

1. Given that I’m the Survey Maker
2. When I try to create a new Survey and included the survey creation costs and survey reward
3. Then I should be able to get the created survey reference number and address

Example #2

1. Given that I’m the Survey Maker
2. When I try to create a new Survey and included the survey creation costs and survey reward
3. Then I should be assigned as the owner of the newly created survey

Example #3

1. Given that I’m the Survey Maker
2. When I try to create a new survey without including the survey creation cost.
3. Then I should receive an Error

Example #4

1. Given that I’m the Survey App Owner
2. When I try to create a new Survey
3. Then I should receive an Error

Below is the code that covers all four examples:

Two things to note from the code above:

1. I didn’t use async/await and used it only in the beforeEach override, this is just a style preference, I usually depend on using chai-as-promised library, but you can still use it as you please.
2. In the second test case, I invoked the method createSurvey first with .call and then without it, the first one is meant to get the result and the second one executes the transaction to be mined by the Ethereum Blockchain (returns a transaction receipt).

2 Update Solidity Code to add enough logic for the test to succeed — Now that we created the test cases we need to make sure the solidity code can make those test cases succeed.

I changed both Solidity contracts to make my test passes, the solidity code now looks like the following:

Things to note here:

1. I might have created more than what the test cases need to pass; this is because I have an architecture and I know specific variables/modifiers would be handy in the future.
2. When you have public/external methods, make sure they emit an event, always!
3. Always be paranoid and do your checks (usually using require) to make sure the method is not continuing with any corrupt state.
4. Also use SafeMath for any arithmetic operations, always!
5. If the contract has Ownership logic, import zeppelin Ownable contract!

3 Test & Repeat — Test the above code by running npm run test to make sure it passes all test cases.

Then repeat the above two steps for another requirement, until we cover all our cases, and our application is ready!

In the Survey DApp, there are four other significant functionalities to test like:

1. Adding Participants
2. Increasing the survey reward
3. Finishing Survey and Draw Winner Randomly
4. Invalidate Survey and pull money out

In the next part

With what we’ve covered in this post, we have successfully looked at how to build the main business logic for the application in a TDD/BDD fashion. We can now deploy the contract and tested it.

The Git repository doesn’t have all test cases covered yet; it would be great if you want to help include it by creating a PR and add the new test-cases and solidity code. However, the full source code with test cases should be available before the next blog post.

agawish/survey-reward-dapp

If you liked this article, consider checking it on steemit, and follow me for more. If you loved it, then don’t forget to click on the green hands right below this text. 👏👏👏

Also, follow me on Twitter!

Building a production-ready Ethereum DApp from idea to final product — The smart-contract (pt. 3) was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous post, I discussed the idea behind the survey DApp, the primary focus of this series. By now you should have a fair understanding of how the interaction between the DApp, the survey taker and survey owner is going to look like — roughly — and now it is time to get started.

But before we dig into the smart contract code we need to understand the tools that we are going to use to set up our development environment.

Table of content

This series is separated into 3 sections:

1. The smart-contract — Create the Survey smart-contract (You’re here)
   1.1. From Idea to a business plan
   1.2. Setting up development environment with Truffle — You’re here
   1.3. Creating the smart-contract the TDD way
   1.4. Testing Solidity Code on TestRPC, Local Ethereum chain and Testnet
2. The Backend — Server side Ethereum development
3. The Frontend — Client side user interface and wallet integration

The smart-contract role of the DApp

We need first to understand how we are going to develop our DApp, the application design is a significant step, as we need to architect application stages properly to avoid code smells in the long run.

The smart-contract is the core module of our DApp, but if we’re part of a team, then the design of the DApp should allow all modules to be loosely coupled, to enable rapid development.

While other parts of the DApp are essential, the smart-contract serves as our business logic, the main point of truth (don’t like to say it is a database!). While validations will exist on both the backend and the frontend, we still want to ensure our data is not corrupted, especially that anyone with the smart-contract address can call its functionality straight away, and that’s why the security of the smart-contract is a keystone to a successful DApp.

Truffle and Web3

Since DApps are literally in their infancy, there are not a lot of frameworks to work with in here, not to mention that the community is currently pushing one specific structure to use, that becomes the defacto nowadays, that is Truffle.

Truffle eases up the development tasks from compiling, testing, migrating/deploying and provide a quick and handy Command Line Interface (CLI) to do all these stuff with ease.

It also provides Truffle Boxes, a prepackaged folder structure that eases up development work with other frameworks like react, uPort and more.

Some of these boxes don’t use the latest versions, so be careful and read your package.json file for dependencies

Unfortunately, Truffle is not a one-size-fits-all framework and therefore is not sufficient. We would still need to work with accounts, BigNumbers, transactions, providers — such as Metamask and Mist — and more, and this is where Web3 comes into the picture.

Web3 simplifies working with all that is Ethereum such as accounts, transactions, different providers, Blockchain blocks, gas and much more.

Setting up the environment

Enough talk, lets get coding…

1we need to have the latest version of Node (if you have a non-upgraded Node, you can upgrade it by following this guide).

2download geth(Go Ethereum) as we will need to use in Part 4 (instructions here)

3create the application’s folder structure by below commands (assuming Unix-based platforms)

I installed everything locally (not globally), it is a good practice if you want to distribute your project without having to worry about individual modules availability. However, you might find it useful to install some of these npm modules globally.

After you finish, you should end up with the below structure (Minus the LICENSE, .env-sample and .gitignore files)

Now time to configure some of these modules to be ready.

Additional npm modules configuration

Now that we sat up the application folder structure, it is good to go through some of these modules to understand their role in the DApp and add its specific configurations.

zeppelin-solidity

zeppelin-solidity is a fantastic npm module that helps with common solidity patterns, not to mention that these contracts have been audited for security so you can safely depend on them. We are going to see how to use these contracts in the next part.

solium

solium is another excellent npm module as it provides lint and preliminary security for solidity code and can also — sometimes — fix these problems, it also helps if you’re working with teams and want to force particular style format.

One thing we don’t want it to analyse is the Migrations.sol contract that comes with Truffle. To ignore it, we need to add the solium ignore list. We can do that by easily open .soliumignore file and add the following line at the end.

contracts/Migrations.sol

We also need to be able to run Solium a lot; it is a good practice to add a script to it inside package.json file like so

"lint": "./node_modules/.bin/solium -d contracts --fix"

solidity-coverage

solidity-coverage is yet another excellent npm module that works in tandem with truffle test command; it generates test coverage report which can be useful, especially if you’re following TDD practices.

First, we need to create the configuration file for solidity-coverage, namely .solcover.js and add the following inside of it

module.exports = {

//Make sure that all open zeppelin contracts are included as a dependency

copyPackages: ['zeppelin-solidity'],

//If we want to skip files

skipFiles: []

};

It is also useful to add solidity-coverage as a script into package.json like so:

"coverage": "./node_modules/.bin/solidity-coverage"

dotenv

dotenv is simply a .env file that load all the properties inside of it into an environment variables, which can be handy especially when we develop server-side code.

ganache-cli

ganache-cli is part of the Truffle suite; it is JavaScript-based Ethereum Blockchain simulator that runs locally which is useful to run different tests and make sure that everything is working as intended.

It is also essential to add ganache-cli as a script into package.json like so:

"testrpc": "./node_modules/.bin/ganache-cli --accounts 30"

In the above command, I’ve changed the default number of generated accounts from 10 to 30.

Truffle

Truffle is the main framework to compile, migrate and test different solidity contracts, we are going to depend on a lot of its functionality throughout this series, but first, we must prepare its configuration.

First, we need to add our the development configuration into truffle.js configuration file.

For windows user, if you have problems with configuration, it would be better to use truffle-config.js file and delete truffle.js file.

The above file is going to grow as we utilise dotenv and test other networks as we move on.

And again it is good to add different truffle commands as a script into package.json like so:

"compile": "./node_modules/.bin/truffle compile",

"test": "./node_modules/.bin/truffle test",

"migrate": "./node_modules/.bin/truffle migrate"

You should finally end up with something similar to the below screen in your package.json file.

In the next part

With what we’ve covered in this post, we are ready to start working on the DApp solidity code; if you found the above too long to follow, you can grab the code from below GitHub repository (make sure you check out the right branch!)

agawish/survey-reward-dapp

If you liked this article, consider checking it on steemit, and follow me for more. If you loved it, then don’t forget to click on the green hands right below this text. 👏👏👏

Also follow me on Twitter!

Building a production-ready Ethereum DApp from idea to final product — The smart-contract (pt. 2) was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

This series is targeting seasoned developers who want a series of articles that revolve around coding best practice to create a production-ready DApps. The developer who has a good understanding of what Blockchain is and how Ethereum smart contract works.

If you need to gain more knowledge about Ethereum and blockchain, check the following post and familiarize yourself with the concept thoroughly.

There are a lot of fantastic guides out there that talks about Ethereum development but usually fall short to show the full picture from the idea all the way to the front-end, back-end and Smart Contract with all of them working together, and all settings and configurations around all that.

Even though I’m targeting a production-ready Ethereum DApp, this tutorial is in no mean the full picture, and won’t guarantee to create a secure app as a security audit would still be needed, and you also need to do your research. But at least I hope to give you enough pointers to know where to go afterwards.

If you care about getting more solidity code and you’re comfortable with the rest, then head to Cyrptozombies.io or follow this guide or that guide, these give an excellent idea of what you need to do.

This series is not going to dig into the specific details of Solidity language or deep dive into the JavaScript and Node.js code, but instead on how to take an idea from the origin and orchestrate the work needed to make everything work. However, if you need any help or more explanation, you can let me know in a comment below.

These posts are going to be short and sweet. It will also be progressive with things getting added as the series goes on. If it attracts enough audience, I can create another series of standard applications like ICOs, Sidechains and more…

Table of contents

This series is separated into 3 layers:

1. The smart-contract — Create the Survey smart-contract
   1.1. From Idea to a business plan — (You’re here)
   1.2. Setting up development environment with Truffle
   1.3. Creating the smart-contract the TDD way
   1.4. Testing Solidity Code on TestRPC, Local Ethereum chain and Testnet
2. The Backend — Server side Ethereum development
3. The Frontend — Client side user interface and wallet integration

The idea

As part of my dissertation, I need to conduct a survey to collect information, and I always hit the problem that people would like to be incentivized for the time they spent — wasted — filling that survey. It would be good if you can compensate them. But wait you’re looking to pay 10s or 100s or even 1000s of people, that would cost a lot of money, wouldn’t it!

Then it hits you…

A raffle, a raffle is a good option, but then people will start question the authenticity and randomness of that raffle and whether or not you’ve given it to someone you know to save yourself this few bucks!

To solve that problem, you design an excellent survey rewarding DApp to assure authenticity to participants and also to deter away people who don’t understand what Ethereum wallet mean ;)

The user(s) journey

The user journey can all be elaborated in the following sequence diagram

There are 3 actors of this DApp:

1. Survey Creator
2. Survey Participant
3. Survey DApp (The connection between both parties)

Survey Creator’s perspective

1. The user Goes to the DApp
2. The user Enters the reward and on clicks on Create Survey Link
3. The user is Prompted from Metamask to confirm Transaction (Creates smart-contract instance)
4. The user is filling the survey link and add integration to survey monkey (out-of-scope)

After the survey is done, the Survey creator can close — announce it is finished — and receive the winner’s details.

Survey Participant’s perspective

1. The user navigates to the Survey DApp.
2. The user clicks on to take the survey link.
3. The user fills in the survey.
4. The user clicks on Finish survey.
5. A popup comes that prompt the user to enter his ETH account address to claim his/her reward later.
6. The user puts his address.
7. A few seconds later the user gets a number to save.

If the participant is the lucky winner, then the participant gets notified, which he/she can withdraw their money into their wallet.

In the next part

With the above you hopefully got the idea of how the DApp is going to look like, in the next part we will see how to create your development environment and what kind of problems you’d usually face setting it up on different Operating Systems, and how to overcome them.

If you liked this article, consider checking it on steemit, and follow me for more. If you loved it, then don’t forget to click on the green hands right below this text. 👏👏👏

Also follow me on Twitter!

Building a production-ready Ethereum DApp from idea to final product — The smart-contract (pt. 1) was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Continuing my journey after finishing Part 2, now that everything in place I want a good place to host my bot and monitor its progress.

Table of Content

• Part 0 — The Setup
• Part 1 — The Project structure
• Part 2 — Developing the bot
• Part 3 — Deploying the bot to Heroku (You are here)

The first rule about Discord bots

The first rule about Disrcord bot, we don’t talk about Discord bots!

The truth about Chat bots, especially the Discord User Bots — not webhook bots — is that you don’t need to deploy them. You just need a computer that is connected to the internet and your bot listening to the socket connection, and you should be good to go.

But since we are in the cloud era, it makes sense to host your bot elsewhere and Heroku is a great place to host your Node.js application.

I first ran my bot on my private server, even when the internet connection was always there, I had a lot of trouble with web socket connection going down periodically, and connecting via VNC or SSH to my server and restarting it was troublesome, even with solutions like Forever, the connection were never stable, so I decided to go for Heroku and it was a great decision!

Pros and Cons of deploying to Heroku

There are multiple things you need to worry about when deploying to Heroku or any other cloud provider:

1. Bots don’t have any UI Interface, so you have to check the log or have a monitoring dyno in order to track your application health.
2. Free dynos may not suitable for your bot, since your bot is going to be idle a lot of the times, and Heroku automatically put them into an idle state when they are not used — This is useful in a web interface, not so much for a bot! — which stops all socket connections!
3. Unless you have a robust Error Handling built in, Heroku won’t be able to tell you if things are not working!

However there are a good news in here, some of them are:

1. Heroku provides you with a public URL, which can be used for webhooks and integration with other messaging platforms like Facebook messanger, Line and others.
2. Heroku has a lot of integrations between different AI/ML engines that can make your bot a lot smarter.
3. You get Continuous Integration for Free, just push your code and everything is redeployed and updated!

Deploying to Heroku

Everything is ready for Heroku, just hook it to my Github repository or use the Heroku CLI and you should be good to go.

Heroku also uses Foreman to load your Environment variables and you can utilise that in your bot to save the API Keys and token in these environment variables — good if you open source your project — instead of your config file.

In my case I just needed to add a start script to my package.json— since my main entry point is not “server.js” — and I’m good to go!

So my package.json becomes something like this:

{

"name": "trials-bot",

"version": "1.0.0",

"description": "Trials of Osiris Discrod Bot",

"main": "app.js",

"scripts": {

"start": "node app.js",

"test": "echo \"Error: no test specified\" && exit 1"

},

"keywords": [],

...
}

And we are done, now you have our bot hosted in Heroku and working with Discord.js!

Taking your bot a step further

Since you have a public URL for your bot, why not utilise it!

Just creating a static HTML page with a minimal bootstrap template to show case your bots commands and maybe a screenshot can be useful right!

And that is exactly what I did, I didn’t want to do anything fancy, just a static HTML page describing the bot and that is it.

First I added express as a dependency.

npm install express --save

I downloaded Bootstrap template — I went for the cover theme — and put everything in “public” folder, so my structure became something like this:

├───lib/
│    └───services/
│          └───bungie.service.js
│    └───commands/
│          └───command.js
│          └───command.registry.js
│          └───help.command.js
├───conf/
│    └───config.js
├───public/
│    └───js/*
│    └───css/*
│    └───img/*
│    └───index.html
├───app.js
├───package.jso

I made sure my index.html looks nice offline, and I added the below code to my app.js

And voila, now I can see my bot website in action, and the bot is secretly running in the background, here is how it looks.

Marketing your bot

The bot is there, but you still need to tell the people what it is and how to use it through different commands.

The perfect place to market your Discord bot is by adding it to the unofficial Discord bot marketplace.

This way users can search what it is, check the website, and even know the technology behind it. The portal makes it really easy for Server/Guild admins to search and add your bot to their channels, just make sure you add the important searchable keywords in your bot description.

Final words

Hope you liked this series of posts about the journey I went through from converting this bot from Java to Node.js, I’ll open source the project soon so check back later.

Overall I’m glad that I made the switch, Node.js community is very vibrant and it is a great match for such projects. All my bots are going to be developed with Node.js from now on!

If you have any questions, please don’t hesitate to ask in the comment section, and leave a ❤ if you liked this post.

Thanks, Amr.

My journey with Discord bots from Java to Node.js — Part 3 (Final) Deploying the bot to Heroku was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Continuing my journey from Part 1, after having a not-so-bad project structure, I needed to make sure I’m being totally DRY and using the best practice of Node.JS!

Table of Content

• Part 0 — The Setup
• Part 1 — The Project structure
• Part 2 — Developing the bot (You are here)
• Part 3 — Deploying the bot to Heroku

Defining the Service Layer

In my previous article I decided to create a service layer, each service would consume a specific RESTful APIs source. I used 3 services: Bungie, GuardianGG and DestinyTrialsReport.

So I created 3 service files, since I’m using Node.JS version 6, I opted to use the best practice for ES6, which has definition for Classes and has a much cleaner syntax.

I also avoided using var and opted to use let and const instead, this made my life a little bit easier.

Here is how my Bungie Service looks

As you can notice, I felt right at home with that new structure, since Classes is the main construct in Java and this structure looks very familiar.

Organising different Bot commands

In order to optimize the registry of different commands for my bot, I used a CommandRegistry to register different commands — I later discovered that it exist as part of core Discord.js library — so I can do something like the following:

The registry is a simple regex — It can capture spaces within quotes as a single entity — and calls the callback method (second-argument) when the message issued a command. It also works on Mention only, so you need to mention the bot in Discord for this to trigger, which was my use case.

My CommandRegistry class was following the below structure:

I also had a list of commands since I can listen to the wildcard, but needed to make sure it’s not being called when another command is there.

Also I replaced the previous structure from Listeners to Commands and opted for the below structure:

├───lib/
│    └───services/
│          └───bungie.service.js
│    └───commands/
│          └───command.js
│          └───command.registry.js
│          └───help.command.js
├───conf/
│    └───config.js
├───app.js
├───package.json

So the last piece of work I needed to do is to create my commands, so for Instance the help.command.js looked like

Note that I used inheritance here, since I have multiple commands, and I wanted to reuse as much parts as I can.

Conclusion

I was pretty happy with the architecture and everything worked out pretty well for me, and I think it can be easily understood and navigated.

The only thing missing for me is to actually deploy the application and see its fruit in action.

In the next and final article I’m going to talk about that process.

My journey with Discord bots from Java to Node.js — Part 2 Developing the bot was originally published in kblog on Medium, where people are continuing the conversation by highlighting and responding to this story.