Programming Language

From BC$ MobileTV Wiki
(Redirected from MVC)
Jump to: navigation, search

A Programming Language is a formal language and method of controlling a machine (or type of machines) using instructions.


The following categories represent the most popular types of programming languages in existence today:

Paradigms

Imperative

  1. Ruby
  2. C#
  3. ASP
  4. JSP
  5. PHP
  6. Python
  7. Perl

Logical

  1. Prolog
  2. F-logic
  3. Rule bases (for running Rule Engines)

Procedural

  1. C
  2. Bash/Shell
  3. Batch/Powershell scripts
  4. IBM RPG

Object-Oriented

  1. Java
  2. C++
  3. Smalltalk

[1]

Declarative

  1. Groovy (DSL syntax)
  2. Lisp
  3. SQL
  4. SPARQL
  5. CSS
  6. HTML/HTML5
  7. XML/xHTML
  8. YAML

[2] [3] [4] [5] [6]

Fluent

  1. jQuery

[7]

Functional

  1. JavaScript
  2. Scala
  3. LISP
  4. Assembly Language
  5. Machine Language
  6. APL

[8] [9] [10]

Reactive

  1. Swift
  2. Kotlin
  3. Rx (various cross-platform libraries)

[11] [12]


Code Metrics

Software Quality Attributes (commonly abbreviated SQA) may potentially display visible symptoms externally when there are issues, but the argument of those who closely measure, monitor and maintain Code Metrics believe the roots of such problems are commonly invisible internal quality attributes such as: program structure, complexity, coupling, testability, reusability, readability, maintainability. There are many possible metrics to look into, however it is commonly accepted that Coupling, Complexity, Cohesion and Size are the fundamental internal quality attributes of a software program.

There are many ways of measuring and assessing these 4 fundametnal SQA, for instance, the following are the Code Metrics measured by CodeMR tool, which has become one of the leading OSS options (with a basic free product and more comprehensive commercial offering):

  1. Coupling - aim for lower coupling (impact of changes in one area to other areas, unintended side-effects, etc)
  2. LCohesion - Lack of Cohesion measures how well the methods of a class are related to each other. High cohesion (low lack of cohesion) tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.
  3. Complexity - Implies being difficult to understand and describes the interactions between a number of entities. Higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes.
  4. Size - one of the oldest and most common forms of software measurement. Measured by the number of lines or methods in the code. A very high count might indicate that a class or method is trying to do too much work and should be split up. It might also indicate that the class might be hard to maintain.
  5. CLOC - Class Lines of Code measures the number of all nonempty, non-commented lines of the body of the class. CLOC is a measure of size and also indirectly related to the class complexity.
  6. WMC - Weighted Method Count is the weighted sum of all class’ methods and represents the McCabe complexity of a class. It is equal to number of methods, if the complexity is taken as 1 for each method. The number of methods and complexity can be used to predict development, maintaining and testing effort estimation. In inheritance if base class has high number of method, it affects its' child classes and all methods are represented in sub-clasess. If number of methods is high, that class possibly domain spesific. Thefore they are less reusable. Also these classes tend to more change and defect prone.
  7. DIT - Depth of Inheritance Tree is the position of the class in the inheritance tree. Has 0 (zero) value for root and non-inherited classes.For the multiple inheritance, the metric shows the maximum length. Deeper class in the inheritance tree, probably inherit. Therefore, it is harder to predict its behavior. Also this class relatively complex to develop, test and maintain.
  8. NOC - Number of Children is the number of direct subclasses of a class. The size of NOC approximately indicates how an application reuses itself. It is assumed that the more children a class has, the more responsibility there is on the maintainer of the class not to break the children's behaviour. As a result, it is harder to modify the class and requires more testing.
  9. CBO - Coupling Between Object Classes is the number of classes that a class is coupled to. It is calculated by counting other classes whose attributes or methods are used by a class, plus those that use the attributes or methods of the given class. Inheritance relations are excluded. As a measure of coupling CBO metric is related with reusability and testability of the class. More coupling means that the code becomes more difficult to maintain because changes in other classes can also cause changes in that class. Therefore these classes are less reusable and need more testing effort.
  10. CBO_LIB - The number of dependent library classes.
  11. CBO_APP - The number of dependent classes in the application.
  12. RFC - Response For a Class is the number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. It includes the full call graph of any method called from the originating method.If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
  13. SRFC - Simple Response For a Class is the number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. It includes methods directly invoced from the class. If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
  14. LCOM - Lack of Cohesion of Methods measures how methods of a class are related to each other. Low cohesion means that the class implements more than one responsibility. A change request by either a Bug or a new feature, on one of these responsibilities will result in a change of that class, which greatly increases likelihood of further Regression Defects. Lack of cohesion also influences understandability and implies classes should probably be split into two or more subclasses.
  15. LCOM3 - varies between 0 and 2. Values 1..2 are considered alarming. In a normal class whose methods access the class's own variables, LCOM3 varies between 0 (high cohesion) and 1 (no cohesion). When LCOM3=0, each method accesses all variables. This indicates the highest possible cohesion. LCOM3=1 indicates extreme lack of cohesion. In this case, the class should be split. When there are variables that are not accessed by any of the class's methods, 1 < LCOM3 <= 2. This happens if the variables are dead or they are only accessed outside the class. Both cases represent a design flaw. The class is a candidate for rewriting as a module. Alternatively, the class variables should be encapsulated with accessor methods or properties. There may also be some dead variables to remove. If there are no more than one method in a class, LCOM3 is undefined. If there are no variables in a class, LCOM3 is undefined. An undefined LCOM3 is displayed as zero [1]. LCOM3 is calculated as follows: LCOM3 = (m - sum(mA)/a) / (m-1) where: m is number of procedures (methods) in class, a is number of variables (attributes) in class and contains all variables whether shared (static) or not, mA is number of methods that access a variable (attribute), sum(mA) is the sum of mA over attributes of a class.
  16. LCAM - Lack of Cohesion Among Methods (also referred to as "1-CAM")... CAM metric is the measure of cohesion based on parameter types of methods.
  17. NOF - Number of Fields (properties/attributes) in a class.
  18. NOM - Number of Methods in a class.
  19. NOSF - Number of Static Fields in a class.
  20. NOSM - Number of Static Methods in a class.
  21. SI - Specialization Index is defined as NORM # DIT / NOM... the Specialization Index metric measures the extent to which subclasses override their ancestors classes. This index is the ratio between the number of overridden methods and total number of methods in a Class, weighted by the depth of inheritance for this class. Lorenz and Kidd precise : Methods that invoke the superclass’ method or override template are not included.
  22. CM-LOC - Class-Methods Lines of Code is the total number of all nonempty, non-commented lines of methods inside a class.
  23. NoI - Number of Interfaces is the total number of Interfaces.
  24. NoCls - Number of Classes is the total number of classes in this project or specific module/package being examined.
  25. NoE - Number of Entities is the total number of Interfaces and classes.
  26. NORM - Number of Overridden Methods is the number of Overridden Methods.
  27. C3 - The max value of Coupling, Cohesion, Complexity metrics.
  28. nofP - Number of Packages in the project.
  29. nofPa - Number of External Packages is the number of External Packages referenced by the project.
  30. nofEE - Number of External Entities is the number of External classes and interfaces referenced by the project.
  31. NoPC - Number of Problematic Classes is the number of classes with high coupling, high complexity or low cohesion in the project.
  32. NoHPC - Number of Highly Problematic Classes is the number of classes with high coupling, high complexity and low cohesion in the project.
  33. LTCC - Lack of Tight Class Cohesion tric measures the lack cohesion between the public methods of a class. That is the relative number of directly connected public methods in the class. Classes having a high lack of cohesion indicate errors in the design.
  34. ATFD - Access to Foreign Data is the number of classes whose attributes are directly or indirectly reachable from the investiggated class. Classes with a high ATFD value rely strongly on data of other classes and that can be the sign of the God Class.
  35. I - Instability metric is used to measure the relative susceptibility of class to changes. It is defined as the ration of outgoing dependencies to all package dependencies and it accepts value from 0 to 1, and is calculated as follows: Instability = EC / (EC+AC) where: EC is Efferent Coupling measures "Outgoing Coupling" or the number of classes in other packages that the classes in the package depend upon is an indicator of the package's dependence on externalities, and, AC is Afferent Coupling measures "Incoming Coupling" or the number of classes in other packages that depend upon classes within the package is an indicator of the package's responsibility.
  36. Abs - Abstractness metric is used to measure the degree of abstraction of the package. abstractness is defines as the number of abstract classes in the package to the number of all classes.
  37. ND - Normalized Distance metric is used to measure the balance between stability and abstractness and is calculated as: ND = |Abs + I - 1|
  38. InDegree - In-degree of corresponding graph vertex of the class.
  39. OutDegree - Out-degree of corresponding graph vertex of the class.
  40. Degree - Degree of corresponding graph vertex of the class.

[13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]


Code Ownership

[25] [26] [27] [28] [29] [30] [31] [32]

Collective

All of the codebase is owned by the entire Dev team, and responsibility for the quality is shared amongst all sub-teams and each of the team members equally. There are no leads in this model, everyone is considered to be at the same level for all changes.

Flexible

The codebase is divided up into modules or logically related sections with each assigned a respective owner/lead and potentially a secondary lead if deemed necessary; but developers are allowed to change modules owned by other people through the team's defined Code Review process.

Strict

Very defined & intentional strategy where codebase is broken up into very granular modules (classes, functions, files) and each module assigned to one developer to take the lead and a secondary (as much as possible the "secondary" should be from another team), other devs then only allowed to make changes to modules they own or by special request to someone else's module; without such a request the owner or backup lead must be the ones to make the change.


Design Principles

[33] [34]


DRY

SOLID

[35] [36] [37] [38] [39]

YAGNI

KISS

SoC

Modularization

Coupling

Coupling occurs between two classes A and B if: 

   A has an attribute that refers to (is of type) B.
   A calls on services of an object B.
   A has a method that references B (via return type or parameter).
   A has a local variable which type is class B.
   A is a subclass of (or implements) class B.

Tight-Coupling

Tightly coupled systems tend to exhibit the following characteristics: 

   A change in a class usually forces a ripple effect of changes in other classes.
   Require more effort and/or time due to the increased dependency.
   Might be harder to reuse a class because dependent classes must be included.


Loose-Coupling

Cohesion

Low Cohesion

High Cohesion

Design Patterns

[40] [41]


Creational Patterns

[42]

Singleton

[43] [44]

Abstraction

Also commonly known as "Abstract Factory" pattern.

Factory Methods

Builder

Object Pool

Prototype

Service Locator

Often combined with Factory pattern to implement a layer of interfaces between Server and Client.

[45]


Structural Patterns

Adapter

[46]

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

Behavioral Patterns

Observer


Chain of Responsibility

Command

Iterator

Mediator

Memento

State

Strategy

Template Method

Visitor

Architectures

MVC

Model View Controller (commonly abbreviated MVC) is one of the most prevalent architectural approach for building complex UI-centric applications on the web, mobile or desktop. It evolved from a number of advances in computer science but is particularly attributed to Tygve Reenskaug

[47] [48] [49] [50] [51] [52] [53]

MVVM

MVP



Approaches

No Code

[54] [55] [56] [57]

Low Code

[58] [59] [60] [61] [62]


Cowboy Coding

Every man, woman and child for themselves mindset programming, reminiscent of the Wild West. Development done in a silo, using whatever tools, languages or technologies one prefers, with little to no consideration to team/dept/organizational fit, maintainability, or broader long-term business value. Usually no documentation or coding standards.


Rapid Prototyping

Chaos Coding

Anti-pattern to quality/productivity.


RDD

Requirements Driven Design, typically paired with Waterfall, depends on analysts to deliver complete, detailed requirements to programmers for implementation with little to no collaboration before this hand-off. Requirements must be vetted for business value before reaching developers.

DDD

Design Driven, all functionality, look & feel details provided up-front, just turn an existing diagram/drawing/wireframe/storyboard into something that works in real life as described.


Pseudo-Coding

TDD

BDD


Pair-Programming

Teaming up between two specific team members (typically developers, but could be a developer with a tester, or, a developer and designer) to collaborate on delivery of a specific Backlog item (Story, Task, Bug fix, Project, Feature, etc).

[63] [64] [65] [66]

Mob Programming

Also known as "Boardroom Programming" or "mobbing". Can be an anti-pattern if not relegated to very specific problem-solving, and if not constituting a very small portion of total coding efforts/outputs. While the "go-to" shouldn't be mobbing for every single Backlog item or issue worked on, it should be a reliable technique to use particularly for new tasks where there is a higher than normal degree of uncertainty where a broad spectrum of ideas is likely to produce the best solution, and also the best cross-team knowledge sharing.

[67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87]

Interviews

[88]

[89] [90] [91]

[92] [93] [94] [95] [96] [97]

[98] [99] [100] [101] [102]

[104] [105] [106] [107] [108]

[110]

Certifications


Tools

  • Emmet: https://emmet.io/ | DOWNLOAD (HTML/CSS shortcut tool for web developers... type a CSS selecter/regex and auto-generate HTML templates or vice-versa CSS rules for a template)
  • Bubble: https://bubble.is/ (info toolkit for data-driven apps/websites without code)

E-Learning

Top programming E-Learning resources/courses/services include:

[114] [115] [116] [117]


Resources

[122]

[123] [124] [125] [126] [127] [128]

[133] [134]

[135] [136] [137] [138] [139] [140]

[141] [142] [143] [144] [145] [146] [147] [148] [149] [150]


Tutorials


External Links

[159]


References

  1. ↑ Object Design Checklist: https://mcsee.medium.com/object-design-checklist-47c63d351352
  2. ↑ wikipedia: Declarative programming
  3. ↑ The Complete Guide to Declarative Programming: https://www.capitalone.com/tech/cloud/declarative-programming-guide/
  4. ↑ Declarative programming -- When “what” is more important than “how”: https://www.ionos.com/digitalguide/websites/web-development/declarative-programming/
  5. ↑ CSS is a Declarative, Domain-Specific Programming Language: https://notlaura.com/css-is-a-programming-language/
  6. ↑ Object-Oriented CSS -- What, How, and Why: https://code.tutsplus.com/tutorials/object-oriented-css-what-how-and-why--net-6986 (technique to match a Declarative programming language like CSS to a more OO mindset)
  7. ↑ wikipedia: List of programming languages by category
  8. ↑ FP vs. OO List Processing: http://blog.cleancoder.com/uncle-bob/2018/12/17/FPvsOO-List-processing.html
  9. ↑ Functional Programming Patterns -- A Cookbook: https://medium.freecodecamp.org/functional-programming-patterns-cookbook-3a0dfe2d7e0a
  10. ↑ Object-Oriented Programming — The Trillion Dollar Disaster: https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 (opinion piece heavily favoring "Functional Programming" paradigms/languages over OOP)
  11. ↑ wikipedia: Reactive programming
  12. ↑ The Reactive Principles: https://principles.reactive.foundation
  13. ↑ Architectural Quality Assessment with CodeMR: https://codemr.medium.com/architectural-quality-assessment-with-codemr-f15de87a8d56
  14. ↑ Supported Metric List by CodeMR: https://codemr.medium.com/supported-metric-list-by-codemr-a119c3cffc2d
  15. ↑ What is the fascination with code metrics?: https://stackoverflow.com/questions/195887/what-is-the-fascination-with-code-metrics
  16. ↑ What code metric(s) convince you that provided code is “crappy”?: https://stackoverflow.com/questions/187289/what-code-metrics-convince-you-that-provided-code-is-crappy
  17. ↑ Visual Studio - Code metrics values: https://docs.microsoft.com/en-us/visualstudio/code-quality/code-metrics-values?view=vs-2019
  18. ↑ How to Generate code metrics data (in Visual Studio): https://docs.microsoft.com/en-us/visualstudio/code-quality/how-to-generate-code-metrics-data?view=vs-2019
  19. ↑ Measure Your Code Using Code Metrics: https://www.c-sharpcorner.com/article/measure-your-code-using-code-metrics/
  20. ↑ A Survey of Metrics for UML Class Diagrams: http://www.jot.fm/issues/issue_2005_11/article1/
  21. ↑ Eclipse - Metrics plugin: http://metrics.sourceforge.net/
  22. ↑ How to Measure Code Quality - 7 Metrics Every Engineer Should Know: https://www.stepsize.com/blog/how-to-measure-code-quality-7-metrics-every-engineer-should-know
  23. ↑ We Can't Measure Programmer Productivity… or Can We?: http://java.dzone.com/articles/we-cant-measure-programmer
  24. ↑ Measuring Software Complexity - What Metrics to Use?: https://thevaluable.dev/complexity-metrics-software/
  25. ↑ Capitalism, Socialism, and Code Ownership: https://blog.scottlogic.com/2021/09/30/Collective-Code-Ownership.html
  26. ↑ Martin Fowler on Code Ownership types: https://martinfowler.com/bliki/CodeOwnership.html
  27. ↑ Martin Fowler - Shifting To Code Ownership: https://martinfowler.com/bliki/ShiftingToCodeOwnership.html
  28. ↑ Weak Code Ownership in detail: http://blog.jayfields.com/2015/02/experience-report-weak-code-ownership.html (our team started out using this approach)
  29. ↑ DZONE - Code Ownership – Who Should Own the Code?: https://dzone.com/articles/code-ownership-–-who-should
  30. ↑ Microsoft -- Don’t Touch My Code! - Examining the Effects of Ownership on Software Quality: https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F150498%2Fbird2011dtm.pdf
  31. ↑ Scaling Collective Code Ownership & Code Reviews at LinkedIn - Nikolai Avteniev: https://www.brighttalk.com/webcast/5742/333544
  32. ↑ Capitalism, Socialism, and Code Ownership: https://blog.scottlogic.com/2021/09/30/Collective-Code-Ownership.html
  33. ↑ The 7 Virtues of Good Software Design: https://dzone.com/articles/the-seven-virtues-of-a-good-design
  34. ↑ Software Architecture Cheat Sheet for Daily Usage: https://azeynalli1990.medium.com/software-architecture-cheat-sheet-for-daily-usage-9923922ea75b
  35. ↑ Design Principles and Design Patterns - by Rob "Uncle Bob" Martin (2000): https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf
  36. ↑ A Solid Guide to SOLID Principles: https://www.baeldung.com/solid-principles
  37. ↑ Why every element of SOLID is (according to this author) wrong: https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong
  38. ↑ Solid Relevance: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html (Uncle Bob's response to Dan North's "Write Simple Code rather than following SOLID" talk)
  39. ↑ CUPID – the back story: https://dannorth.net/2021/03/16/cupid-the-back-story/ (a bold claim that ever principle of SOLID is wrong)
  40. ↑ DesignPatterns implemented in JAVA: https://github.com/gkatzioura/DesignPatterns
  41. ↑ In28Mins -- Design Patterns for Beginners with Java examples: https://dzone.com/articles/design-patterns-for-beginners-with-java-examples
  42. ↑ How to Build Creational Design Patterns: Singleton Pattern: https://dzone.com/articles/creational-design-patterns-singleton-pattern
  43. ↑ Introducing the Single Element Pattern: https://medium.freecodecamp.org/introducing-the-single-element-pattern-dfbd2c295c5d | SRC
  44. ↑ WRITING TESTABLE CODEPRESENTATIONS Singletons are Pathological Liars: http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
  45. ↑ Design Patterns Explained – Service Locator Pattern with Code Examples: https://stackify.com/service-locator-pattern/
  46. ↑ Usage of the Adapter pattern in Java: https://refactoring.guru/design-patterns/adapter/java/example#lang-features
  47. ↑ wikipedia: Trygve Reenskaug (researcher who coined the term "MVC")
  48. ↑ The original MVC reports Trygve Reenskaug Dept. of Informatics University of Oslo: https://www.duo.uio.no/bitstream/handle/10852/9621/Reenskaug-MVC.pdf?sequence=1
  49. ↑ The Model-View-Controller (MVC) -- Its Past and PresentTrygve Reenskaug, University of Oslo: https://folk.universitetetioslo.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf | BACKUP
  50. ↑ MODELS - VIEWS - CONTROLLERS originakl 1979 whitepaper: https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-12-MVC.pdf
  51. ↑ Origins of Model View Controller: https://medium.com/@duncandevs/origins-of-model-view-controller-d685528857ce
  52. ↑ Do MVC like it’s 1979 (on iOS/Swift): https://medium.com/bumble-tech/do-mvc-like-its-1979-da62304f6568
  53. ↑ Trygve Reenskaug's MVC specification applied to a Java Swing GUI app: https://codereview.stackexchange.com/questions/163146/trygve-reenskaug-s-mvc-specification
  54. ↑ New to "No Code"? Start Here: https://kissflow.com/low-code/no-code/no-code-overview/
  55. ↑ Stripe’s first no-code product -- Payment Links: https://www.producthunt.com/newsletter/8463-stripe-s-first-no-code-product-payment-links
  56. ↑ Plasmic: https://www.plasmic.app (visual builder for your tech stack)
  57. ↑ AppSmith: https://www.appsmith.com (powerful open source framework to build internal tools)
  58. ↑ TechRepbulic -- REPORT - "Low-code" tech is the future for businesses and entrepreneurs: https://www.techrepublic.com/article/report-low-code-tech-is-the-future-for-businesses-and-entrepreneurs/
  59. ↑ Is "Low-code" the best “new” technology breakthrough: https://www.prolim.com/low-code-the-best-new-technology-breakthrough/
  60. ↑ 10 Best Low-Code Development Platforms in 2021: https://www.softwaretestinghelp.com/low-code-development-platforms/
  61. ↑ Introducing "Microsoft PowerFx" -- the low-code programming language for everyone: https://powerapps.microsoft.com/en-us/blog/introducing-microsoft-power-fx-the-low-code-programming-language-for-everyone/
  62. ↑ AppWrite: https://appwrite.io (Secure Open-Source Backend Server for Web, Mobile & Flutter Developers)
  63. ↑ Pair Programming and Why We Do It: https://dzone.com/articles/pair-programming-at-codacy-and-why-we-do-it-1
  64. ↑ Pair Programming (aka. Pairing): https://www.agilealliance.org/glossary/pairing
  65. ↑ What Is Pair Programming? Advantages and Challenges: https://dzone.com/articles/what-is-pair-programming-advantages-challenges-tut
  66. ↑ On Pair Programming: https://martinfowler.com/articles/on-pair-programming.html
  67. ↑ Teaching using Mob Programming: http://blog.code-cop.org/2014/09/teaching-using-mob-programming.html
  68. ↑ A Day of Mobbing: https://www.youtube.com/watch?v=p_pvslS4gEI
  69. ↑ "Mob Programming" Time Lapse: https://www.youtube.com/watch?v=Ev7uus12HRY
  70. ↑ A day of Mob Programming 2016: https://www.youtube.com/watch?v=dVqUcNKVbYg
  71. ↑ Mob Programming: https://www.infoq.com/presentations/mob-programming
  72. ↑ Woody Zuill on Mob Programming and No Estimates: https://www.infoq.com/interviews/zuill-mob-programming
  73. ↑ Agile Alliance -- Mob Programming – A Whole Team Approach (explained by Woody Zuill): https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/
  74. ↑ GOTO 2017 conference -- Mob Programming - A Whole Team Approach (Woody Zuill): https://www.youtube.com/watch?v=SHOVVnRB4h0
  75. ↑ Mob programming and shared everything: https://blog.codecentric.de/en/2020/02/mob-programming-shared-everything/
  76. ↑ Team-oriented development: https://blog.codecentric.de/en/2020/04/team-oriented-development/
  77. ↑ How to Find the Right Collaborative Coding Tool for Remote Pair Programming: https://dzone.com/articles/the-right-collaborative-coding-tool-for-remote-pair-programming
  78. ↑ The Surprisingly Inclusive Benefits of Mob Programming: https://cucumber.io/blog/inclusive-benefits-of-mob-programming/
  79. ↑ Mob Programming - the Good, the Bad and the Great: https://underthehood.meltwater.com/blog/2016/06/01/mob-programming/
  80. ↑ Speed Up Your Scrum With Mob Programming : https://www.scrum.org/resources/blog/speed-your-scrum-mob-programming
  81. ↑ How Mob Programming Will Make You More Effective: https://hackernoon.com/how-mob-programming-will-make-you-more-effective-590a1b7e0418
  82. ↑ I did mob programming every day for 5 months -- here’s what I learnt: https://medium.com/comparethemarket/i-did-mob-programming-every-day-for-5-months-heres-what-i-learnt-b586fb8b67c
  83. ↑ Mob Programming – A Whole Team Approach: https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Zuill_.pdf
  84. ↑ InfoQ -- Mob Programming overview (VIDEO): https://www.infoq.com/presentations/mob-programming
  85. ↑ Ping-Pong, Paired Programing (VIDEO): https://thoughtbot.com/upcase/videos/ping-pong-paired-programing
  86. ↑ The Secret to a Great Planning Process — Lessons from Airbnb and Eventbrite: https://review.firstround.com/the-secret-to-a-great-planning-process-lessons-from-airbnb-and-eventbrite
  87. ↑ Don’t do Code Review, try Mob instead: https://medium.com/verotel/dont-do-code-review-try-mob-instead-82149ef035df
  88. ↑ 7 Brain Tips for Software Developers: http://www.javacodegeeks.com/2014/12/7-brain-tips-for-software-developers.html
  89. ↑ The 7 Highest Paying Companies for Tech Workers in 2021: https://medium.com/@SomeTechGuru/the-top-7-paying-companies-for-tech-workers-in-2021-3b51dabf99b7
  90. ↑ Why Don’t Tech Companies Pay Their Engineers to Stay?: https://marker.medium.com/why-dont-tech-companies-pay-their-engineers-to-stay-b9c7e4b751e9
  91. ↑ The Argument for Location-Based Salaries Is Falling Apart: https://www.wired.co.uk/article/location-based-salary-discrepancy
  92. ↑ Cracking The Coding Interview - 12 Things You Need To Know: http://dotnet.dzone.com/articles/cracking-coding-interview-12
  93. ↑ Top 10 OOP Concepts Interview Questions: http://www.instanceofjava.com/2015/03/oops-concepts-interview-questions.html
  94. ↑ 10 Tricky Core-Java Interview Questions: http://javaconceptoftheday.com/tricky-core-java-interview-coding-questions/
  95. ↑ 7 Programmer Recruiting Mistakes: http://en.codeceo.com/7-programmer-recruiting-mistakes.html
  96. ↑ Resume Writing & Interviewing Skills: http://slideplayer.com/slide/5942078/
  97. ↑ Unifying the Technical Interview: https://aphyr.com/posts/354-unifying-the-technical-interview
  98. ↑ How to Prepare for Your DevOps Interview: https://dzone.com/articles/how-to-prepare-for-your-devops-interview
  99. ↑ Your DevOps Interview: https://itchronicles.com/devops/your-devops-interview/
  100. ↑ What’s Your Favorite DevOps Interview Question? 20 DevOps Pros Share Their Favorite Questions and How Developers Can Prepare: https://stackify.com/devops-interview-questions/
  101. ↑ DevOps interview questions: How to prepare: https://raygun.com/blog/devops-interview-questions/
  102. ↑ Top 8 DevOps Interview Preparation Tips: https://www.coachdevops.com/2019/07/tips-for-attending-devops-interviews.html
  103. ↑ Database of JAVA interview questions: http://javasearch.buggybread.com/InterviewQuestions/questionSearch.php
  104. ↑ Most Frequently Asked Java Interview Questions: https://blog.usejournal.com/most-frequently-java-interview-question-127e923f70d9
  105. ↑ Top 20 Java Interview Questions by Hiring Investment Banks: https://dzone.com/articles/top-20-java-interview-questions-with-answers
  106. ↑ Senior Developers are Getting Rejected for Jobs: https://glenmccallum.com/2019/05/14/senior-developers-rejected-jobs/
  107. ↑ The Best of Java Interview Questions: https://dzone.com/articles/interview-question-cluster
  108. ↑ 50+ Java Interview Questions for Programmers: https://dzone.com/articles/50-java-interview-questions-for-programmers
  109. ↑ Cracking the (Frontend) Coding Interview: https://blog.usejournal.com/cracking-the-frontend-coding-interview-ec7d5b1e6755 (with old-school vanilla JS)
  110. ↑ Recruiting Software Developers – Coding Tests (are they needed, and how to prepare): https://henrikwarne.com/2021/04/19/recruiting-software-developers-coding-tests/
  111. ↑ Codecademy, the free online coding school, raises another $30M led by Naspers: https://techcrunch.com/2016/07/12/codecademy-the-free-online-coding-school-raises-another-30m-led-by-naspers/
  112. ↑ GLOT - Selenium Python "Headless Chrome" Test example: https://glot.io/snippets/ew3ok1nh2g
  113. ↑ wikipedia: The Typing of the Dead
  114. ↑ Web Development Tools You Need to Know by the End of 2014: http://java.dzone.com/articles/web-development-tools-you-need
  115. ↑ Top 20 Developer Tools of 2016: http://dzone.com/articles/top-20-developer-tools-of-2016-1
  116. ↑ 17 key dev tools for 2017: http://dzone.com/articles/top-17-tools-used-in-software-development
  117. ↑ Get your kids coding with Minecraft: https://developer.atlassian.com/blog/2016/02/get-your-kids-coding-with-minecraft/ | EXAMPLE
  118. ↑ Which programming languages are most popular (and what does that even mean)?: http://www.zdnet.com/article/which-programming-languages-are-most-popular-and-what-does-that-even-mean/
  119. ↑ PYPL PopularitY of Programming Language: http://pypl.github.io/PYPL.html
  120. ↑ The 9 Most In-Demand Programming Languages of 2016: http://www.codingdojo.com/blog/9-most-in-demand-programming-languages-of-2016/
  121. ↑ How Popular is JavaScript in 2019?: https://medium.com/javascript-scene/how-popular-is-javascript-in-2019-823712f7c4b1
  122. ↑ Sorting Algorithms visualized: https://www.reddit.com/r/educationalgifs/comments/5fcfe4/sorting_algorithms_visualized/
  123. ↑ Biased Algorithms Learn From Biased Data - 3 Kinds Biases Found In AI Datasets: https://www.forbes.com/sites/cognitiveworld/2020/02/07/biased-algorithms/
  124. ↑ Algorithmic Bias - Why Bother?: https://cmr.berkeley.edu/2020/11/algorithmic-bias/
  125. ↑ Bias In AI Algorithms: https://towardsdatascience.com/how-are-algorithms-biased-8449406aaa83
  126. ↑ Babysitting Racist Algorithms: https://www.mediapost.com/publications/article/364336/babysitting-racist-algorithms.html
  127. ↑ Google ‘fixed’ its racist algorithm by removing gorillas from its image-labeling tech: https://www.theverge.com/2018/1/12/16882408/google-racist-gorillas-photo-recognition-algorithm-ai
  128. ↑ Google Searching For New Skin Tone Measures To Reduce Bias: https://www.mediapost.com/publications/article/364335/google-searching-for-new-skin-tone-measures-to-red.html
  129. ↑ Design patterns, the big picture, Part 1 -- Design pattern history and classification (Part 1 of 3): http://www.javaworld.com/article/2078665/core-java/design-patterns--the-big-picture--part-1--design-pattern-history-and-classification.html
  130. ↑ Design patterns, the big picture, Part 2 -- Gang-of-four classics revisited: http://www.javaworld.com/article/2078675/core-java/design-patterns--the-big-picture--part-2--gang-of-four-classics-revisited.html
  131. ↑ Design patterns, the big picture, Part 3 -- Beyond software design patterns: http://www.javaworld.com/article/2071208/core-java/design-patterns--the-big-picture--part-3--beyond-software-design-patterns.html
  132. ↑ A Software Developer’s Guide to Side Projects: https://dzone.com/articles/a-software-developers-guide-to-side-projects
  133. ↑ Learn to Code with Star Wars: https://code.org/starwars
  134. ↑ Minecraft Hour of Code Tutorials https://code.org/minecraft
  135. ↑ Monolith to Microservices Using the Strangler Pattern: https://dzone.com/articles/monolith-to-microservices-using-the-strangler-patt
  136. ↑ Strangler Applications: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
  137. ↑ Sharing UI Components to Build Consistent UIs Faster: https://medium.com/javascript-in-plain-english/sharing-ui-components-to-build-consistent-uis-faster-5e60141ca855
  138. ↑ Switching from LESS to SASS with the Strangler Pattern: https://hoyer.io/LESS-to-SASS-with-Strangler-Pattern/
  139. ↑ Strangler Applications: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
  140. ↑ Chopping the monolith: https://blog.frankel.ch/chopping-monolith/
  141. ↑ Naming Conventions From Uncle Bob's Clean Code Philosophy: https://dzone.com/articles/naming-conventions-from-uncle-bobs-clean-code-phil
  142. ↑ 5 Tips to Master the Art of Clean Code: https://mrshrestha.medium.com/5-tips-to-master-the-art-of-clean-code-cdd11a25b372
  143. ↑ What Is Clean Code?: https://medium.com/s/story/reflections-on-clean-code-8c9b683277ca
  144. ↑ How to make your code better with intention-revealing function names: https://medium.freecodecamp.org/how-to-make-your-code-better-with-intention-revealing-function-names-6c8b5271693e
  145. ↑ Why 4 spaces are used as the unit of indentation in Java?: https://stackoverflow.com/questions/4802381/why-4-spaces-are-used-as-the-unit-of-indentation-in-java
  146. ↑ Why are spaces preferred over tabs as indentation in Python?: https://www.reddit.com/r/learnpython/comments/34dpn4/why_are_spaces_preferred_over_tabs_as_indentation/
  147. ↑ Domain-Oriented Observability: https://martinfowler.com/articles/domain-oriented-observability.html
  148. ↑ The Clean Code Talks - Don't Look For Things!: https://www.youtube.com/watch?v=RlfLCWKxHJ0
  149. ↑ 10 Must-Have React Developer Tools to Write Clean Code: https://dev.to/alexomeyer/10-must-have-react-developer-tools-to-write-clean-code-1808
  150. ↑ Every second matters - the hidden costs of unoptimized "Developer workflows": https://humanitec.com/blog/hidden-costs-of-unoptimized-developer-workflows (excellent chart of max. time to spend to save a certain amount of time, based on frequency of the task carried out)
  151. ↑ The Well-Grounded Java Developer: http://manning.com/evans/
  152. ↑ Eclipse Collections Kata: https://github.com/eclipse/eclipse-collections-kata
  153. ↑ JVM Calendar -- 19 Lessons in a Kata: https://dzone.com/articles/jvm-calendar-19-lessons-in-a-kata
  154. ↑ Code Kata: http://codekata.com/
  155. ↑ Elvis operator etymology: https://stackoverflow.com/questions/35844113/elvis-operator-etymology
  156. ↑ Tabs vs Spaces -- How They Write Java at Google, Twitter, Mozilla and Pied Piper: https://blog.takipi.com/tabs-vs-spaces-how-they-write-java-in-google-twitter-mozilla-and-pied-piper/
  157. ↑ * Linus Torvalds on 80-character code limit being outdated, suggests 142: https://lkml.org/lkml/2020/5/29/1038
  158. ↑ Refactoring comics/infographics: http://llewellynfalco.blogspot.com/p/infographics.html
  159. ↑ Leak of Microsoft Salaries Shows Fight for Higher Compensation: https://onezero.medium.com/leak-of-microsoft-salaries-shows-fight-for-higher-compensation-3010c589b41e
  160. ↑ Changelog podcast #463 - 10,000 hours concept applied to development: https://changelog.com/podcast/463

See Also

Programming Languages | IDE | E-Learning | Technology/TechDebt | Virtualization | Docker | OS | Device | Client/Server | API | Testing | CI/CD/CDD | DevOps | Agile | PM | Productivity | LAMP | MEAN | WebApp | DesktopApp | Mobile App

Retrieved from "http://wiki.bcmoney-mobiletv.com/index.php?title=Programming_Language&oldid=60081#MVC"