When I interview a Java developer, if I see Spring Boot or Spring on the candidate’s resume, I may start with a simple question: “What is the default scope for a Spring bean”? Most people would get it right. I would then follow with a tricky question: “Does Spring make sure a Singleton bean thread-safe?” or “Does developer need to do anything to make sure a Singleton bean thread-safe?”.
When I say “tricky”, not because it’s tricky technically, but because half interviewees have no idea. The other half who correctly answered don’t always demonstrate solid understanding of Singleton and thread-safety. It’s okay to guess at an interview I guess.
Spring Boot is one of those popular frameworks for Java developers. Like most other Java frameworks, it provides proven reusable libraries and increases productivity. Some developers can probably make a living by simply being good at it.
However, because it encapsulates the interpretation of various Java Specifications, hides the complexity of design and implementation, often the framework itself imposes a serious impediment for developers to understand the underlining fundamentals.
Many Spring Boot developers don’t know Spring Boot is just a framework on top of another popular framework Spring Framework, which was initially a framework for Java Servlet applications. Most freshly-minted Spring Boot developers never heard of Servlet, not to mention web.xml. They only know their Spring Boot applications, “just run”. They never know why and how it runs.
Because of that, they never think of what the underlining Servlet Container is, what the default configurations (like Max Concurrent Requests) are, and how to fine tune those configurations. Imagine asking them to write a Java Web Application without Spring Boot?
Frameworks tend to wrap a lot of default features and behaviors under the hood, just to name a few: default Encryption Algorithm, default Socket Timeout, default Retry Strategy.
In the past, Frameworks might have configuration property for each “feature”, but this has changed in the recent years. Nowadays, Framework authors tend to favor “Convention over configuration”. Old configuration files are replaced by annotations with “sensible defaults”. Moreover, many of the features and behaviors are “discovered” automatically based on your running environments, like system properties, environment variables and what is in the class-path.
Several years back, I led a framework team. We built a Framework as the foundation for a slew of web applications that support multi-million $ business. We worked very hard to support all major features by default, and still allow each application to extend and override each feature by configuration and automatic discovery. I learned first hand, it’s even harder for application developers to fully understand how each feature worked and how to extend or override them.
Naturally, due to the lack of visibility and transparency of frameworks, people makes a lot of assumptions about frameworks, such as Singleton bean thread-safety. Some of the assumptions will definitely haunt the team down the road if the technical leads on the team didn’t review the design and code carefully.
Overtime, frameworks will evolve or die. If you ever worked with Struts 1.x framework, and if you didn’t understand Java Servlet, you would have a difficult time to migrate your applications to Struts 2.x or Spring.
Frameworks are your tools, not your crutches. If you don’t think out of the box of Spring Boot, you can’t professionally outgrow Spring Boot. Simple. Period.
That is true to other frameworks too.
Frameworks can help you get started quickly, but understanding the underlining principles will help you in the long run.
To build resilient software applications, when architecting the integration points with downstream services, we shall consider all error scenarios. Robust error handling is essential. Retrying remote API calls is an important part.
A retry can be done either synchronously or asynchronously. If the clients require a response of the execution status, not just the acknowledgement of the receipt of the request, it’s appropriate to implement synchronous retries with limits on total retry numbers and time. On the other hand, if the clients don’t care about the actual execution status, or have ways to receive responses asynchronously, it is almost always a good idea to adopt asynchronous retry architecture. Of course, before putting a request into asynchronous retry process, we can always implement synchronous retry first whenever it makes sense.
In this article, we will focus on the asynchronous retry architecture.
2. Queuing for Asynchronous Retry Architecture
Queuing mechanism is the center of the Asynchronous Retry Architecture.
The originating service constructs a Retry Message that includes the original request info, the destination URL and other metadata, puts the Retry Message into an Async Retry Queue based on the chosen queuing system. A trigger could be configured in the queue to trigger a processor. Or, an Async Retry Processor can pull the queuing system for new messages. The Async Retry Processor can then utilize the message received from the Async Retry Queue and make another call to the destination downstream service.
A Dead Letter Queue is used to hold Retry Messages for certain period time after a (configurable) maximum number of retries have been reached.
The below figure is a very high level workflow and message flow:
3. Asynchronous Retry Architecture Diagram
Asynchronous Retry Architecture
In the above diagram, Service A is the calling service and Service B is the destination downstream service. If the initial call in Step 1 fails, Service A will put a Retry Message into the Async Retry Queue.
Depends on what Queuing System is chosen, either a trigger can be configured in the Async Retry Queue to trigger the Processor (3.1), or a Processor can be configured to poll the Async Retry Queue (3.2). If AWS SQS is chosen as the queuing system, a Lambda function can be configured to trigger the processor when a new message arrives.
Once the Async Retry Processor receives the Retry Message, it can use the request info in the message to reconstruct the request, and send the request to the destination URL that is also included in the retry message.
A Retry Message will be moved to the Dead Letter Queue if the maximum retry attempts have been reached as detected by the Async Retry Processor or the Async Retry Queue.
4.Generic Data Model for Retry Message
A Retry Message can have a generic data model as below:
<span id="60ab" class="hc wp tx so wq b gg wr ws x wt" data-selectable-paragraph="">{
"request":{
"url":"http[s]://$host:$port/$destitnation_endpoint_including_query_parameters",
"method":"GET|POST|PUT|DELETE|PATCH",
"payload":"$json_string",
"headers":[$headers_to_pass_to_the_target_service]
},
"receivedCount": "$number",
"async-retry-queue":"$async-retry-queue[optional]",
"dead-letter-queue":"$dead-letter-queue[optional]"
}</span>
With this generic data model design for Retry Message, an Async Retry Processor can be designed to process any Retry Message constructed by any originating services (Service A) to any destination services (Service B).
5. Retryable Errors
Only non-functional errors are retryable. Below are some examples:
a. No response at all;
b. Temporary Network issue, usually 5xx (http status) errors;
c. Request timeout: http status 408 errors;
d. Conflict: http status 409 errors;
e. Too many request: http status 429
f. If there is a Retry-After header in the http response of the downstream service;
h. Unauthorized: http status 401 errors with expired token error code/message. These kind of errors usually require a new token. In this case, the Async Retry Processor is responsible for getting the proper token.
6. Conclusion
Asynchronous Retry Architecture can be used to handle all retryable errors when the client is not expecting the execution result in the response of the call. It is extremely useful if a function may need to be tried many times for a long period of time.
The number of maximum retry attempts, the async retry queue name/url, and the dead letter queue name/url can all be configurable. The configurable values can make architecture flexible for many different applications.
You and a partner go into business together and split the equity 50/50. You do all the work and your partner slacks off. He owns half your business- now what?
Slicing Pie outlines a process for calculating exactly the right number of shares each founder or employee in an early stage company deserves.
You will learn:
How to value the time and resources an individual brings to the company relative to the contributions of others
The right way to value intangible things like ideas and relationships
What to do when a founder leaves your company
How to handle equity when you have to fire someone
Important issues to discuss with your lawyer
Much more
Research shows that dynamic equity split models, like the one outlined in Slicing Pie, is the best way to avoid conflicts as the company grows.
The new and improved Version 2.3 contains updated information about legal issues, idea valuation, retrofitting and much more!
Often downplayed in the excitement of starting up a new business venture is one of the most important decisions entrepreneurs will face: should they go it alone, or bring in cofounders, hires, and investors to help build the business? More than just financial rewards are at stake. Friendships and relationships can suffer. Bad decisions at the inception of a promising venture lay the foundations for its eventual ruin. The Founder’s Dilemmas is the first book to examine the early decisions by entrepreneurs that can make or break a startup and its team. Drawing on a decade of research, Noam Wasserman reveals the common pitfalls founders face and how to avoid them. He looks at whether it is a good idea to cofound with friends or relatives, how and when to split the equity within the founding team, and how to recognize when a successful founder-CEO should exit or be fired. Wasserman explains how to anticipate, avoid, or recover from disastrous mistakes that can splinter a founding team, strip founders of control, and leave founders without a financial payoff for their hard work and innovative ideas. He highlights the need at each step to strike a careful balance between controlling the startup and attracting the best resources to grow it, and demonstrates why the easy short-term choice is often the most perilous in the long term. The Founder’s Dilemmas draws on the inside stories of founders like Evan Williams of Twitter and Tim Westergren of Pandora, while mining quantitative data on almost ten thousand founders. People problems are the leading cause of failure in startups. This book offers solutions.
As each new generation of entrepreneurs emerges, there is a renewed interest in how venture capital deals come together. Yet there is little reliable information focused on venture capital deals. Nobody understands this better than authors Brad Feld and Jason Mendelson. For more than twenty years, they’ve been involved in hundreds of venture capital financings, and now, with the Second Edition of Venture Deals, they continue to share their experiences in this field with you.
Engaging and informative, this reliable resource skillfully outlines the essential elements of the venture capital term sheet–from terms related to economics to terms related to control. It strives to give a balanced view of the particular terms along with the strategies to getting to a fair deal. In addition to examining the nuts and bolts of the term sheet, Venture Deals, Second Edition also introduces you to the various participants in the process and discusses how fundraising works.
Fully updated to reflect the intricacies of startups and entrepreneurship in today’s dynamic economic environment
Offers valuable insights into venture capital deal structure and strategies
Brings a level of transparency to a process that is rarely well understood
Whether you’re an experienced or aspiring entrepreneur, venture capitalist, or lawyer who partakes in these particular types of deals, you will benefit from the insights found throughout this new book.
模式识别=机器学习。两者的主要区别在于前者是从工业界发展起来的概念,后者则主要源自计算机学科。在著名的《Pattern Recognition And Machine Learning》这本书中,Christopher M. Bishop在开头是这样说的“模式识别源自工业界,而机器学习来自于计算机学科。不过,它们中的活动可以被视为同一个领域的两个方面,同时在过去的10年间,它们都有了长足的发展”。
Steve McConnell’s Code Complete 2 is the Joy of Cooking for software developers. Reading it means that you enjoy your work, you’re serious about what you do, and you want to keep improving. In Code Complete, Steve notes that the average programmer reads less than one technical book per year. The very act of reading this book already sets you apart from probably ninety percent of your fellow developers. In a good way.
I like this book so much that the title of this very website is derived from it – the examples of what not to do are tagged with the “Coding Horror” icon. There’s nothing funnier than a Coding Horror – until you have to deal with one yourself. Then it’s suddenly not so funny any more. Do yourself a favor. Make this the first book you read, and the first book you recommend to your fellow developers.
Arguably the only classic book in our field. If you haven’t read it, shame on you.
I challenge any developer to pick up a copy of The Mythical Man Month and not find this tale of a long-defunct OS, and the long-defunct team that developed it, startlingly relevant. This twenty-five year old book boldly illustrates one point: computers may change, but people don’t.
Reading this classic work will certainly be a better use of your time than poring over the latest thousand page technical tome du jour.
The single best book on usability I’ve ever read. The title says “web usability” but don’t be fooled by its faux specificity. Steve Krug covers every important usability concept in this book, and covers it well. It’s almost fun. If you choose to read only one book on usability, choose this one. It’s chock full of great information, and it’s presented in a concise, approachable format. It’s suitable for any audience: technical, non-technical, user, developer, manager, you name it.
Er… yeah. Never been in a meeting like that. The solution to this problem, by the way, is quick and dirty usability testing. Imagine that: making decisions based on actual data instead of never ending, last man standing filibuster style religious debates. Revolutionary!
The full title of this book is Rapid Development: Taming Wild Software Development Schedules, which isn’t just long-winded and vaguely ridiculous, it’s also an unfortunate misnomer.
Rapid Development isn’t about rapid development. It’s about* the reality of failure* . The vast majority of software development projects will fail: they will overrun their schedules, produce substandard results, or sometimes not even finish at all. This isn’t an argument; it’s a statistical fact. The unpleasant truth is that your team has to be very good to simply avoid failing, much less to succeed. While that may sound depressing – okay, it is depressing– you’ll still want to read this book.
Why? Because half* of success is not repeating the same mistakes you, or other people, have made. The epiphany offered in this book is that making mistakes is good– so long as they are all new, all singing, all dancing mistakes. If you’re making the same old classic mistakes, you’ve failed before you’ve even begun. And you probably have no idea how likely it is that you’re making one of these mistakes right now.
Our field is one of the few where change is the only constant, so it’s only natural to embrace that change and try different “Rapid” development techniques. But the converse isn’t true. We can’t assume that so much has changed since 1970 that all the old software development lessons are obsolete and irrelevant when compared to our hot new technology. It’s the same old story: computers have changed; people haven’t. At least have some idea of what works and what doesn’t before you start– in McConnell’s words, “read the instructions on the paint can before painting.” Sure, it sounds obvious enough until you read this book and realize how rarely that actually happens in our field.
* According to the book, technically, one-quarter. But I think it’s more than that.
If you’ve ever seen the performance of an all-star sports team suffer due to poor coaching, you’ll appreciate this book. It doesn’t matter how many “coding superstars” you’ve got when none of them can talk to each other, or agree on anything. And it no developer, however talented, can work effectively when constantly being barraged with minor interruptions. Developers aren’t known for their people skills, per se, but here’s the ironic part: the success of your project may hinge on just that. If you have any legitimate aspirations to be a “Team Leader” in practice instead of in name only, you need to pick up a copy of this book.
While Peopleware is full of great, totally valid points, it also implies a level of employee control over the workplace that is pure fantasy at most companies. But at least you’ll know when your work environment, or your team, are the real problem – and more importantly, what to do about it.
It can be incredibly frustrating to develop software, because so much can go wrong. A lot of what we do is defensive: trying to anticipate what will go wrong before it does. It’s mentally fatiguing, and can eventually manifest itself in some negative ways. I sometimes describe this to non-technical people as building a watch with a thousand moving parts, all of which can fail randomly at the slightest provocation. Good times!
Designing software is difficult, to be sure, but designing a door is difficult too. The nuances of design extend into every object you touch, whether it’s some hot new SQL engine, or a humble shoe. This book will give you a new appreciation of the “devil in the details.” If designing a door isn’t the no-brainer we thought it was, maybe it’s time to give ourselves a break for not being able to design software perfectly, either.
Alan Cooper, father of Visual Basic, godfather of usability. I’ve owned a few versions of this book now (this is version four), and it is the rare book which is getting better and better as it is revised, and more authors are added for different perspectives.
About Face is full of generally applicable guidelines for mobile and web. Of the GUI problems used for illustration – with examples from the hoary old Windows 95 UI – it’s interesting to compare which have been mostly resolved (using visual examples to show the effects of dialog selections before you make them), and which have not (stopping the proceedings with modal idiocy).
It’s a fantastically useful book; I’ve used whole chapters as guides for projects I worked on.
This is the book that introduced the world to the concept of personas: rather than thinking of users as an abstract, difficult-to-describe, amorphous group of people, personas instruct us to talk about specific users who have names, personalities, needs, and goals. Would our users want a print preview feature? Who knows? But if Gerry Manheim, Account Executive, has to print out his weekly expense report as a part of his job, you better believe print preview needs to be in there. There’s nothing magical here; as always, it boils down to knowing who your users are and what they really do – and the personas technique is a great way to get there.
There’s also an interesting analysis here of how developers tend to think themselves qualified to make usability decisions on behalf of “regular” users, when in reality they’re anything but. Developers are freakish, extreme users at best– “Homo Logicus” versus “Homo Sapiens.” Unless you happen to be writing a compiler where developers are the end users.
One hidden lesson in this book is that sometimes it doesn’t matter how good your design is: the scanner software and the web development software which Alan consulted on, and uses as examples in this book, both failed in the marketplace for reasons that had nothing to do with their usability– which was verifiably excellent.* Sometimes great products fail for reasons beyond your control, no matter how hard you try. Feel free to use this fact to counterbalance the sometimes bombastic tone of the book.
* I owned the exact model of “behind the keyboard” USB scanner pictured in the book, and I was quite impressed with the bundled scanning software. I eventually gave this scanner to my Dad. One time I was chatting on the phone with him and without any prompting at all, he mentioned to me how much he liked the scanning software. This was before the book had been published!
I hesitated to include Programming Pearls because it covers some fairly low-level coding techniques, but there are enough “pearls” of software craftsmanship embedded in this book to make it well worth any developer’s time. Any book containing this graph..
.. is worth its weight in gold. TRS-80 versus DEC Alpha to illustrate 48n versus n3 algorithms? Come on folks, it just doesn’t get any better than that. Programming Pearls is the next best thing to working side by side with a master programmer for a year or so. It is the collective wisdom of many journeyman coders distilled into succinct, digestible columns.
I won’t lie to you: there are entire chapters that can probably be ignored. For example, I can’t imagine implementing sorting, heap, or hash algorithms as documented in columns 11, 13, and 14 respectively, given today’s mature libraries of such basic primitives. But for every textbook-tedious exercise, there is real, practical advice alongside. Just scan through the book, ignoring the code sections, and I doubt you’ll be disappointed. Column 8, “Back of the Envelope” is essential, probably the best treatment of estimation I’ve seen anywhere. It also goes a long way towards explaining those crazy interview questions that companies love to annoy us with.
You can read sample sections of the book online if you’re still on the fence. I recently used the chapter on strings to illustrate the use of Markov chains in generating synthetic data to fill an empty database with – a performance estimation technique covered in “Back of the Envelope”.
This book reminds me a lot of Programming Pearls, but it’s actually better, because it’s less focused on code. Instead of worrying about code, the authors boiled down all the practical approaches that they’ve found to work in the real world into this one book. Not all of these things are technically programming. For example, asking yourself “why am I doing this? Is this even worth doing at all?” isn’t thinking outside the box; it’s something you should incorporate into your daily routine to keep yourself – and your co-workers – sane. And that’s what makes Pragmatic Programmer such a great book.
Jakob Neilsen is well known for his usability site, and his career as a usability expert extends back to 1989 when his first book was published. Designing Web Usability is of course a full-on web usability primer, so it’s a bit different than the GUI-oriented Cooper books.
UNIX has a well-deserved reputation for being complex and impenetrable. So do Regular Expressions.
I may be a card carrying member of the “Keep It Simple Stupid” club, but I’m making a meteor sized exception for regular expressions. Written properly, they will save you a tremendous amount of time in string manipulation, and I’ve never run across a project where they didn’t come in handy somewhere.
Once you delve into the world of regular expressions, you may become drunk with the amazing power and potential they have, which results in things like Perl. Remember, absolute power corrupts absolutely. But it also rocks absolutely.
The roots of entrepreneurship are old. But, the fruits were never so lucrative as they have been recently. Until 2010, not many of us had heard of the term ‘start-up’. And now, not a day goes by when business newspapers don’t quote them. There is sudden gush in the level of courage which people possess.
Today, I see 1 out of 5 person talking about a new business idea. Some of them even succeed too in establishing their dream company. But, only the determined ones sustain. In data science, the story is bit different.
The success in data science is mainly driven by knowledge of the subject. Entrepreneurs are not required to work at ground level, but must have sound knowledge of how it is being done. What algorithms, tools, techniques are being used to create products & services.
In order to gain this knowledge, you have two ways:
You work for 5-6 years in data science, get to know things around and then start your business.
You start reading books along the way and become confident to start in first few years.
I would opt for second option.
Why read books ?
Think of our brain as a library. And, it’s a HUGE library.
How would an empty library look like? If I close my eyes and imagine, I see dust, spider webs, brownian movement of dust particles and darkness. If this imagination horrifies you, then start reading books.
The books listed below gives immense knowledge and motivation in technology arena. Reading these books will give you the chance to live many different entrepreneurial lives. Take them one by one. Don’t get overwhelmed. I’ve displayed a mix of technical and motivational books for entrepreneurs in data science. Happy Reading!
List of Books
Data Science For Business
This book is written by Foster Provost & Tom Fawcett. It gives a great head start to anyone, who is serious about doing business with big data analytics. It makes you believe, data is now business. No business in the world, can now sustain without leveraging the power of data. This books introduces you to real side of data analysis principles and algorithms without technical stuff. It gives you enough intuition and confidence to lead a team of data scientists and recommend what’s required. More importantly, it teaches you the winning approach to become a master at business problem solving.
This book is written by Thomas H. Davenport. It reveals the increasing importance of big data in organizations. It talks with interesting numbers, researches and statistics. So until 2009, companies worked on data samples. But with advent of powerful devices and data storage capabilities, companies now work on whole data. They don’t want to miss even a single bit of information. This book unveils the real side of big data, it’s influence on our daily lives, on companies and our jobs. As an entrepreneur, it is extremely important for you understand big data and its related terminologies.
This book is written by Alistair Croll and Benjamin Yoskovitz. It’s one of the most appreciated books on data startups. It consist of practical & detailed researches, advice, guidance which can help you to build your startup faster. It gives enough intuition to build data driven products and market them. The language is simple to understand. There are enough real world examples to make you believe, a business needs data analytics like a human needs air. To an entrepreneur, this will introduce the practical side of product development and what it takes to succeed in a red ocean market.
This book is written by Michael Lewis. It’s a brilliant tale which sprinkles some serious inspiration. A guy named billy bean does what most of the world failed to imagine, just by using data and statistics. He paved the path to victory when situations weren’t favorable. Running a business needs continuous motivation. This can be a good place to start with. However, this book involves technical aspects of baseball. Hence, if you don’t know baseball, chances are you might struggle in initial chapters. A movie also has been made on this book. Do watch it!
This book is written by Ashlee Vance. I’m sure none of us are fortunate to live the life of Elon Musk, but this book let’s us dive in his life and experience rise of fantastic future. Elon is the face behind Paypal, Tesla and SpaceX. He has dreamed of making space travel easy and cheap. Recently, he was applauded by Barack Obama for the successful landing of his spaceship in an ocean. People admire him. They want to know his secrets and this is where you can look for. As on entrepreneur, you will learn about must have ingredients which you need to a become successful in technology space.
This book is written by Thomas H Davenport and Jinho Kim. As we all know, data science is driven by numbers & maths (quants). Inspired from moneyball, this book teaches you the methods of using quantitative analysis for decision making. An entrepreneur is a terminal of decision making. One must learn to make decisions using numbers & analysis, rather than intuition. The language of this book is easy to understand and suited for non-maths background people too. Also, this book will make you comfortable with basics statistics and quantitative calculations in the world of business.
The author of this book is Nate Silver, the famous statistician who correctly predicted US Presidential elections in 2012. This books shows the real art and science of making predictions from data. This art involves developing the ability to filter out noise and make correct predictions. It includes interesting examples which conveys the ultimate reason behind success and failure of predictions. With more and more data, predictions have become prone to noise errors. Hence, it is increasingly important to understand the science behind making predictions using big data science. The chapters of this book are interesting and intuitive.
This book is written by Roger Lowenstein. It is an epic story of rise and failure of a hedge fund. For an entrepreneur, this book has ample lessons on investing, market conditions and capital management. It’s a story of a small bank, which used quantitative techniques for bond pricing throughout the world and ensured every invested made gives a profitable results. However, they didn’t sustain for long. Their quick rise was succeeded by failure. And, the impact of their failure was so devastating that US Federal bank stepped in to rescue the bank, because the fund’a bankruptcy would have large negative influence on world’s economy.
This book is written by Eric Ries. In one line, it teaches how to not to fail at the start of your business. It reveals proven strategies which are followed by startups around the world. It has abundance of stories to make you walk on the right path. An entrepreneur should read it when he/she feel like draining out of motivation. It teaches to you to learn quickly, implement new methods and act quickly if something doesn’t work out. This book applies to all industries and is not specific to data science.
This book is written by Avinash Kaushik. It is one of the best book to learn about web analytics. Internet is the fastest mode of collecting data. And, every entrepreneur must learn the art of internet accounting. Most of the businesses today face the challenge of weak presence on social media and internet platforms. Using various proven strategies and actionable insights, this book helps you to solve various challenges which could hamper your way. It also provides a winning template which can be applied in most of the situations. It focuses on choosing the right metric and ways to keep them in control.
This book is written by Eric Seigel. It is a good follow up book after web analytics 2.0. So, once you’ve understood the underlying concept of internet data, metrics and key strategies. This book teaches you the methods of using that knowledge to make predictions. It’s simple to understand and covers many interesting case studies displaying how companies predict our behavior and sell us products. It doesn’t cover technical aspects, but explains the general working on predictive analytics and its applications. You can also check out this funny rap video by Dr. Eric Seigel:
This book is written by Steven D Levitt and Stephen J Dubner. It shows the importance of numbers, data, quantitative analysis using various interesting stories. It says, there is a logic is everything which happens around us. Reading this book will make you aware of the unexplored depth at which data affects our real lives. It draws interesting analogy between school teachers and sumo wrestlers. Also, the bizarre stories featuring cases of criminal acts, real-estate, drug dealers will certainly add up to your exciting moments.
This book is written by Jessica Livingston. Again, this isn’t data science specific but a source of motivation to get you moving forward. It’s a collection of interviews with the founders of various startups across the world. The focus has been kept on early days i.e. how did they act when they started. This book will give you enough proven ideas, strategies and lessons to anticipate and avoid pitfalls in your initial days of business. It consist of stories by Steve Wozniak (Apple), Max Levchin (Paypal), Caterina Fake (Flikr) and many more. In total, there are 32 interviews listed which means you have the chance to learn from 32 mentors in one single book. Must read for entrepreneurs.
This book is written by Greg Gianforte and Marcus Gibson. It teaches about the things to do when you are running short of money and still don’t want to stop. This is a must read book for every entrepreneur. Considering the amount of investment required in data science startups, this book should have a special space in an entrepreneur’s heart. It reveals various eye opening truths and strategies which can help you build a great company. Greg and Marcus proves that money is not always the reason for startup failure, it’s all about founder’s perspective. This book has stories of success and failures, again a great chance for you to live many lives by reading this book.
This book is written by Thomas H Davenport, Jeanne G Harris and Robert Morrison. This books reveals the increased use of analytical tools & concepts by managers to make informed business decisions. The decision making process has accelerated. For a greater impact, it also consists of examples from popular companies like hotels.com, best buy and many more. It talks about recruiting, coordination with people and the use of data and analytics at an enterprise level. Many of us are aware of data and analytics. But, only a few know how to use them together. This quick book has it all !
This marks the end of this list. While compiling this list, I realized most of these books are about sharing experience and learning from the mistake of others. Also, it is immensely important to posses quantitative ability to become good in data science. I would suggest you to make a reading list and stick to it throughout the year. You can take up any book to start. I’d suggest to start with a motivational book.
Have you read any other book ? What were your key takeaways? Did you like reading this article? Do share your knowledge & experiences in the comments below.
如今,三家投资机构正在努力刺激工具和平台的开发,来提高研究者获取和使用这些数据的能力。在华盛顿特区举行的第7届医疗数据研讨会上,(美国)国立卫生研究院(National Institute ofHealth,简称NIH)、总部在英国的威康信托基金(Wellcome Trust)以及霍华德•休斯医学研究所(Howard Hughes Medical Institute)宣布了首届开放科学奖(Open Science Prize)的6支决赛队伍名单。
根据世界卫生组织(World Health Organization)的说法,空气污染是导致8分之1全球死亡病例的罪魁祸首,然而空气质量数据一直被存储在不起眼的网站上,难以访问,同时格式也不一致。OpenAQ平台(https://openaq.org/#/)原型将数据进行了合并和标准化,成为公众可得、实时的空气质量数据。它已经收集和分享了来自13个国家500多个地点的970万空气质量检测数据。
当美国食物和药品管理局(U.S Food and Drug Administration)批准一种药物时,该机构公开发布一系列关于该药物的信息,通常包含先前未公开的临床试验。尽管这些信息相当有价值,但难以获得、收集和搜索。OpenTrialFDA努力建立一个用户友好的网站界面让任何人能访问相关信息,还提供应用接口(API),允许第三方平台接入和搜索数据。(https://www.openscienceprize.org/p/s/1844843/)