What does the future of collaboration look like? Surely not just restricted to just audio and video. Below is an image of what I collected defines presence for people I talked to this weekend:
So many unsolved problems still to solve each of these challenges in a seamless easy to way for consumers.
Sentiment analysis has recently become core part of analytics in chats between customers and brands specially in ones with measure as customers experience like in hospitality. Lot of research has been done and SaaS solutions are available for finding sentiment of a particular utterance but its hard to understand sentiment for conversations that comprises of conclusive utterances happening between two or more parties. This is an open research area and lots of advancements are needed in finding and mainly classifying interactions into states ( e.g. Greeting, Troubleshooting etc. ). An interesting analytics measure for measuring guests satisfaction will be to find transition of sentiments in utterances as they are happening in conversation.
Conversational sentiments via machine learning and rule based is easier however in goal based chatbots where chatbots are programmed to achieve a particular goal and involve transitioning of conversation from one state to another ( e.g., Greetings -> Problem Discovery -> Troubleshooting -> Conclusion ). Please share any research material you have or advice for finding sentiments for human-human conversations.
Productive Idea flow is when ideas keep on building over each other. You arrive at a good idea which is improvement over your current product and spend some time visualising how everything will look and work if that idea is implemented. Then in that state you imagine yourself there and try to find another improvement. This improvement is your next idea built over previous increment. This incremental ideas work over each other to create a new innovative disruptive idea.
e.g. In your thoughts imagine creating a light bulb, then LED, television, computer, mobile etc etc all just by a bulb.
Ever want to check quality of code, always start with quality of code commits. Code commits are generally last priority given by developers in the overall quality maintenance of code. A good code commit history quality is generally a good indicator of a good code quality as well.
As a general rule, don’t go with commit history quality of master branch, as those will be mainly ‘dev’ branch merges, ‘dev’ branch will be feature branch merge history. Feature branch generally are created with ticket id or shortcode of feature. Every feature will having rich commit history generally with ticket id.
Good commit message practices:
1: Written with imperative mood. Generally starts with ticket id followed with keywords as ‘fix’, ‘add’, ‘remove’ and not status update from developers with keywords as ‘fixed’, ‘added’ and ‘removed’. Good example is ‘DEV-21 fix infinite loop in login api’. A bad example is ‘fixed infinite loop in login api’ and a real bad example is ‘login loop in infinite loop will not happen now’
2: Not very short to provide no context, neither very long to create unreadable git commit history.
3: Commits are not ‘end of day’ commits with junk messages like ‘going to bed now’
4: Combining two tickets in the same fix e.g. ‘DEV-21 fix infinite loop in login api and DEV-32 fix logout api’ unless fix of both commits are same code. In which case should have a better format like ‘DEV-32 DEV-21 fix authentication retries check causing infinite loop in login and logout API’
Akhil wants to buy a phone which does not heat up fast, as his phone is to be used in his Uber – always engaged and in sunlight. His favourite ecommerce website can’t understand what he is looking for, yet there are lots of people who want to buy exact same phone. Welcome to the bot world where user will be able to freely tell the exact problem/ use case and not just be thrown up with some filters on category which 2-3 product people decide should exist. Where organisations will learn from one failed reply to user to make sure next time replies will be done around that problem.
The biggest self-created enemy of commerce apps as we will see will be imposing filters on users and not let them tell exactly what they are looking for. Its no surprise now to know that maximum books sold on Amazon when it was launched was books which were not available over major Book Stores. When users are given power to express their exact problems and those are fulfilled, we have always seen a huge business building out in that particular space. How that will be done? – well technology has always enabled organisation achieve what was seen impossible at one point of time and will be easily understood by ones who have first hand experience working in Neural Network or been part of process where humans provide training to machines.
Problem right now for any bot-tech product is getting rich data. And data is very private to each bot or website. Users buying phone over your bot will not be talking or asking in a similar way over Quora. Research and transactions have different behaviour and we already know how user behaviour is different over booking.com and tripadvisor.com. The only way to collect data is to let users type in whatever they want to and express what they are looking for while training algorithms to use this trained data to find exact goal next time. Fast failures is going to be biggest win in bot tech because more the failed data, more is training, better the bot.
Bot tech right now is enabled by available tools like wit.ai, api.ai, luis.ai etc. , but these are going to be intermediary solutions until bots organisations build data enough to self-train and write their own algorithms for ways they want to solve this problem. Then will be a bot-tech war as we had already seen previously in Search Engines.
What we know today is – it’s not going to be about just algorithms, it will be about data (more). And we should care more about user providing us whatever free text solves their problem, while providing replies productive enough to do goal fulfilment as well as narrating bot capabilities.
Lets assume you working on a public github repo e.g., https://github.com/parag/simplenlg-python3 . You have done git clone this repo but now you want to extend this library but privately. You could maintain a new branch ‘dev’ locally or since you are not pushing to master, you can maintain just master branch only. Advice to maintain a different branch though. You could push this ‘dev’ branch to master of your repo.
If you are wondering what is the use case, this is majorly used if your production systems are dependent on the repo and original author is not very active to accept your changes which you want to push to your server.
Imaging you have created a private new repository over bitbucket.
First, checkout a new branch:
git checkout -b dev
Add a new remote in your current local:
git remote add private git@bitbucket.org:paragarora/sp3.git
Now push this branch to master of new private repo
git push -u private dev:master
You could also push public master branch to your private branch
git push -u private master:github_master
I had implemented my last company (Plustxt) product over eJabbered. It worked well for couple of hundred thousand users but after I sold the company to Paytm and implemented for over 50+ million users, we immediately started noticing bottlenecks with scaling XMPP but also more importantly started facing heavy battery drainage in mobile. One of the most critical infrastructure for Glowing is also messaging broker. Inspite of great deal of knowledge sunk-in cost in eJabbered, we took the challenge of exploring for much better and reliable technologies.
Following were salient points we considered before picking the right solution:
A messaging aggregation platform is a platform that is capable of receiving and sending messages to multiple (and popular) messaging platforms. Existing messaging apps installed on user devices act as invisible apps available for and tie into our platform. Benefits for end (consumer) users who consistently rely and use a favorite platform include not needing to install any new apps, let alone change and learn new behavior; but rather, businesses that use a messaging aggregation platform merge into current habits and preferences of users.
Since we are so much focused on messaging layer, internationalisation and localisation is mission critical for us. We explored lots of solutions for incorporating messages for multiple languages but none of the solution worked out of box for us. After doing research, explored we need to zero down to one of the mentioned two options:
1: i18next
2: react-intl
Although both are complementary solutions with react-intl on first looked like eventual solution. But having different string messages for different languages looked like very hacky and react-intl was not infact made for that. Its mainly for localising formats (e.g., date). Also we are already using i18n on our API servers, so i18next looks like an apt choice for the workflow is similar. Here is how to integrate this i18next.