Resources To Improve Your Knowledge

  • (4 Pages)
  • +
  • « First
  • 2
  • 3
  • 4

52 Replies - 72413 Views - Last Post: 02 November 2017 - 06:13 AM

#46 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 04 March 2016 - 01:32 PM

Software Architecture Patterns - free ebook from O'Reilly
Was This Post Helpful? 2
  • +
  • -

#47 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 11 March 2016 - 01:01 PM

An Introduction to Programming in Go
by Caleb Doxsey
2012

http://www.golang-book.com/books/intro
https://www.golang-b...df/gobook.0.pdf
Was This Post Helpful? 0
  • +
  • -

#48 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 24 June 2016 - 01:42 PM

From what I understand this was built around their c language love affair, but JPL's rules can be applied elsewhere..

Quote

NASA’s 10 rules for writing mission-critical code:
  • Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
  • All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
  • Do not use dynamic memory allocation after initialization.
  • No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
  • The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).
  • Data objects must be declared at the smallest possible level of scope.
  • The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
  • The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.
  • The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  • All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

http://fossbytes.com...rules-critical/
http://pixelscommand...2014/12/P10.pdf
Was This Post Helpful? 0
  • +
  • -

#49 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 13 July 2016 - 09:08 AM

The Architecture of Open Source Applications
Free books, yo.

Quote

  • 500 Lines or Less: Experienced Programmers Solve Interesting Problems
  • The Performance of Open Source Applications
  • The Architecture of Open Source Applications vol 1 & 2


In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to these books provide unique insights into how they think.

If you are a junior developer, and want to learn how your more experienced colleagues think, these books are the place to start. If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, these books can help you too.

Was This Post Helpful? 0
  • +
  • -

#50 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 06 December 2016 - 01:32 PM

Quote

Atomic Design
by Brad Frost

We're tasked with making interfaces for more users in more contexts using more browsers on more devices with more screen sizes and more capabilities than ever before. That's a daunting task indeed. Thankfully, design systems are here to help.

Atomic Design details all that goes into creating and maintaining robust design systems, allowing you to roll out higher quality, more consistent UIs faster than ever before. This book introduces a methodology for thinking of our UIs as thoughtful hierarchies, discusses the qualities of effective pattern libraries, and showcases techniques to transform your team's design and development workflow.

http://atomicdesign.bradfrost.com/
Was This Post Helpful? 1
  • +
  • -

#51 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 17 April 2017 - 09:50 AM

A nice look into the hash table concept..

Taking Hash Tables Off The Shelf
Was This Post Helpful? 0
  • +
  • -

#52 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,837
  • Joined: 12-June 08

Re: Resources To Improve Your Knowledge

Posted 07 June 2017 - 07:19 AM

A Gentle Introduction To Graph Theory

Then this tangent for a db:
https://neo4j.com/

Quote

Neo4j is a highly scalable, native graph database purpose-built to leverage not only data but also its relationships.

Neo4j's native graph storage and processing engine deliver constant, real-time performance, helping enterprises build intelligent applications to meet today’s evolving data challenges.

Was This Post Helpful? 0
  • +
  • -

#53 andrewsw  Icon User is offline

  • the case is sol-ved
  • member icon

Reputation: 6375
  • View blog
  • Posts: 25,756
  • Joined: 12-December 12

Re: Resources To Improve Your Knowledge

Posted 02 November 2017 - 06:13 AM

Quote

Public speaking is a required business skill. There's a critical value in being willing and able to communicate effectively with your team, investors, customers, and so on.

Those could be two different things. It is very important to be able to communicate effectively with your team, investors, etc., but public speaking generally refers to an individual speaking to an audience of several, or many, people. Not everyone is required to do this or comfortable doing so.
Was This Post Helpful? 0
  • +
  • -

  • (4 Pages)
  • +
  • « First
  • 2
  • 3
  • 4