This repository was archived by the owner on Aug 8, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.html
More file actions
4881 lines (4491 loc) · 216 KB
/
index.html
File metadata and controls
4881 lines (4491 loc) · 216 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!--
MIT License
Copyright (c) 2020 Alex Arus (Alexander Selivanov)
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
-->
<!DOCTYPE html>
<html dir="ltr" lang="en-US">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="author" content="Alex Arus" />
<meta name="subject" content="Dev Notes" />
<meta name="keywords" content="programming" />
<title>dev-notes</title>
<link href="https://fonts.googleapis.com/css?family=Roboto&display=swap" rel="stylesheet">
<link rel="icon" href="favicon.svg" type="image/svg+xml" />
<link rel="icon" href="favicon.png" type="image/png" />
<style>
html,
body {
margin: 0;
padding: 0;
font-family: 'Roboto', sans-serif;
}
#root {
padding: 5px;
margin: 0 auto;
height: 100%;
width: 100%;
box-sizing: border-box;
word-break: break-word;
}
article {
page-break-before: always;
padding-right: 5px;
}
nav {
display: none;
}
dt {
text-decoration: underline;
}
@supports (display: flex) {
.darkTheme {
background-color: black;
color: white;
}
.lightTheme {
background-color: white;
color: black;
}
.darkTheme a {
color: white;
}
.lightTheme a {
color: black;
}
.darkTheme nav {
background-color: rgba(100, 100, 100, 0.7);
}
.lightTheme nav {
background-color: rgba(150, 150, 150, 0.7);
}
.flex {
display: flex;
flex-wrap: wrap;
justify-content: space-evenly;
align-content: space-between;
}
.block {
display: block;
}
.flex article {
max-width: 450px;
min-width: 200px;
}
nav {
display: block;
position: sticky;
top: 3px;
width: 100%;
padding: 5px;
border-radius: 5px;
font-weight: bolder;
}
#index {
display: flex;
flex-wrap: wrap;
justify-content: space-around;
}
#settings {
text-align: center;
font-size: 12px;
}
nav a {
padding: 5px;
}
a:hover {
text-decoration: underline;
cursor: pointer;
}
#scrollToTop {
position: fixed;
right: 25px;
bottom: 25px;
background-color: darkgray;
color: black;
border-radius: 25px;
padding: 10px;
}
#scrollToTop:hover {
text-decoration: none;
}
}
@media print {
body {
background-color: white !important;
color: black !important;
}
a {
color: darkblue !important;
}
#root {
display: block;
}
article {
max-width: unset !important;
min-width: unset !important;
padding-right: unset !important;
}
nav {
display: none;
}
}
table {
width: 100%;
padding: 5px;
border-spacing: 5px;
border-collapse: separate;
}
td {
padding: 10px;
}
.border {
border: 1px solid lightgray;
}
.strong {
font-weight: bold;
}
.text-center {
text-align: center;
}
.small-font {
font-size: 10px;
}
.page-break-before {
page-break-before: always;
}
</style>
<script>
document.addEventListener('keypress', function (e) {
if (e.keyCode === 13) {
toggleFullScreen();
}
}, false);
function toggleFullScreen() {
if (!document.fullscreenElement) {
document.documentElement.requestFullscreen();
} else {
if (document.exitFullscreen) {
document.exitFullscreen();
}
}
}
function toggleTheme() {
const body = document.querySelector('body');
const darkTheme = 'darkTheme';
const lightTheme = 'lightTheme';
if (Array.from(body.classList).some((cl) => cl === darkTheme)) {
body.classList.replace(darkTheme, lightTheme);
} else {
body.classList.replace(lightTheme, darkTheme);
}
}
function toggleLayout() {
const root = document.getElementById('root');
const blockClass = 'block';
const flexClass = 'flex';
if (Array.from(root.classList).some((cl) => cl === blockClass)) {
root.classList.replace(blockClass, flexClass);
} else {
root.classList.replace(flexClass, blockClass);
}
}
function scrollToTop() {
window.scrollTo(0, 0);
};
document.addEventListener("DOMContentLoaded", () => {
const topics = document.querySelectorAll('h1');
const index = document.getElementById('index');
if (!index) {
return;
}
topics.forEach((topic) => {
const id = topic.textContent;
topic.id = id;
const topicLink = document.createElement('a');
topicLink.innerText = id;
topicLink.href = `#${id}`;
index.appendChild(topicLink);
});
});
</script>
</head>
<body class="darkTheme">
<div id="root" class="flex">
<nav>
<a id="scrollToTop" onclick="scrollToTop()">Up</a>
<div id="settings">
<a onclick="toggleFullScreen()">full screen on/off</a>
<a onclick="toggleTheme()">dark/light theme</a>
<a onclick="toggleLayout()">flex/box</a>
<a href="flashcards/index.html">flashcards</a>
</div>
<div id="index"></div>
</nav>
<article>
<h1>Data structures</h1>
<section>
<h2>Array&List</h2>
<dl>
<dt>Array</dt>
<dt>Dynamic array</dt>
<dt>Linked list</dt>
<dt>Double linked list</dt>
<dt>Stack</dt>
<dt>Queue</dt>
</dl>
</section>
<section>
<h2>Graph&Tree</h2>
<dl>
<dt>Graph</dt>
<dt>Tree</dt>
<dt>Trie (digital/prefix tree)</dt>
<dd>
an ordered tree data structure used to store a dynamic set or associative array where
the keys are usually strings
</dd>
<dt>BST (binary search tree)</dt>
<dd>
<u>left child</u> of a node has value <u></u>less</u> than the parent and
<u>right child</u> has value <u>greater</u> than parent
</dd>
<dt>AVL (Adelson-Velsky and Landis)</dt>
<dd>self-balancing binary search tree</dd>
<dd>
<u>binary search tree</u> with additional property that <u>difference between height
of left sub-tree</u> of any node <u>can't be more than 1</u>
<p>named after inventors Adelson-Velsky and Landis</p>
</dd>
<dt>B-tree</dt>
<dd></dd>
<dt>2–3–4 tree</dt>
<dd></dd>
<dt>Red–black tree</dt>
<dd></dd>
</dl>
</section>
<section>
<h2>Set&Map</h2>
<dl>
<dt>Set</dt>
<dt>Map</dt>
<dt>Hash Map</dt>
</dl>
</section>
<section>
<h2>Matrix</h2>
</section>
</article>
<article>
<h1>Algorithms</h1>
<section>
<h2>Search algorithms</h2>
<dl>
<dt>Linear / Sequential search</dt>
<dt>Binary / Half-interval / Logarithmic / Binary chop search</dt>
<dt>Jump search</dt>
<dt>Interpolation search</dt>
<dt>Exponential /Doubling / Galloping / Struzik search</dt>
<dt>Fibonacci search</dt>
</dl>
</section>
<section>
<h2>Sort algorithms</h2>
<h3>Simple sort (n<sup>2</sup>)</h3>
<dl>
<dt>Insertion sort</dt>
<dt>Selection sort</dt>
</dl>
<h3>Bubble sort and variants (n<sup>2</sup>)</h3>
<dl>
<dt>Bubble sort</dt>
<dt>Comb sort</dt>
</dl>
<dl>
<dt>Shell sort</dt>
<dd>in-place comparison sort, can be seen as either a generalization of sorting by
exchange (bubble sort) or sorting by insertion (insertion sort)</dd>
</dl>
<h3>Efficiant sort (n log n)</h3>
<dl>
<dt>Merge sort</dt>
<dt>Heap sort</dt>
<dt>Quick sort</dt>
</dl>
<h3>Distribution sort</h3>
<dl>
<dt>Counting sort (n+r)</dt>
<dt>Bucket sort (n+k)</dt>
<dt>Radix sort</dt>
</dl>
</section>
<section>
<h2>Graph&Tree traversal</h2>
<dl>
<dt>BFS (Breadth-first search)</dt>
<dd>finding the shortest path (queue)</dd>
<dt>DFS (Depth-first search)</dt>
<dd>edge based technique (stack)</dd>
<p>BFS & DFS Worst-case performance: O(V+E), V - verices, E - edges</p>
</dl>
</section>
</article>
<article>
<h1>SDLC</h1>
<p>Software development life cycle</p>
<section>
<h2>SDLC stages</h2>
<dl>
<dt>Planning and Requirement Analysis</dt>
<dt>Defining Requirements</dt>
<dt>Designing the Product Architecture</dt>
<dt>Building or Developing the Product</dt>
<dt>Testing the Product</dt>
<dt>Deployment in the Market and Maintenance</dt>
</dl>
</section>
<section>
<h2>SDLC methodologies</h2>
<dl>
<dt>Waterfall Model</dt>
<dt>V-Shaped Model</dt>
<dt>Iterative Model</dt>
<dt>Spiral Model</dt>
<dt>Big Bang Model</dt>
<dt>Agile Model</dt>
</dl>
</section>
<section>
<h2>Anti-Patterns</h2>
<h3>Organizational</h3>
<dl>
<dt>Analysis paralysis</dt>
<dd>A project stalled in the analysis phase, unable to achieve support for any of the potential plans of
approach</dd>
<dt>Bicycle shed</dt>
<dd>Giving disproportionate weight to trivial issues</dd>
<dt>Bleeding edge</dt>
<dd>Operating with cutting-edge technologies that are still untested or unstable leading to cost overruns,
under-performance or delayed delivery</dd>
<dt>Bystander apathy</dt>
<dd>The phenomenon in which people are less likely to or do not offer help to a person in need when others are
present</dd>
<dt>Cash cow</dt>
<dd>A profitable legacy product that often leads to complacency about new products</dd>
<dt>Design by committee</dt>
<dd>The result of having many contributors to a design, but no unifying vision</dd>
<dt>Escalation of commitment</dt>
<dd>Failing to revoke a decision when it proves wrong</dd>
<dt>Groupthink</dt>
<dd>A collective state where group members begin to (often unknowingly) think alike and reject differing
viewpoints</dd>
<dt>Management by objectives</dt>
<dd>Management by numbers, focus exclusively on quantitative management criteria, when these are non-essential
or cost too much to acquire</dd>
<dt>Micromanagement</dt>
<dd>Ineffectiveness from excessive observation, supervision, or other hands-on involvement from management
</dd>
<dt>Moral hazard</dt>
<dd>Insulating a decision-maker from the consequences of their decision</dd>
<dt>Mushroom management</dt>
<dd>Keeping employees "in the dark and fed manure" (also "left to stew and finally canned")</dd>
<dt>Peter principle</dt>
<dd>Continually promoting otherwise well-performing employees up to their level of incompetence, where they
remain indefinitely[4]</dd>
<dt>Seagull management</dt>
<dd>Management in which managers only interact with employees when a problem arises, when they "fly in, make a
lot of noise, dump on everyone, do not solve the problem, then fly out"</dd>
<dt>Stovepipe or Silos</dt>
<dd>An organizational structure of isolated or semi-isolated teams, in which too many communications take
place
up and down the hierarchy, rather than directly with other teams across the organization</dd>
<dt>Typecasting</dt>
<dd>Locking successful employees into overly safe, narrowly defined, predictable roles based on their past
successes rather than their potential</dd>
<dt>Vendor lock-in</dt>
<dd>Making a system excessively dependent on an externally supplied component</dd>
</dl>
<h3>Project management</h3>
<dl>
<dt>Cart before the horse</dt>
<dd>Focusing too many resources on a stage of a project out of its sequence</dd>
<dt>Death march</dt>
<dd>A project whose staff, while expecting it to fail, are compelled to continue, often with much overwork, by
management which is in denial[5]</dd>
<dt>Ninety-ninety rule</dt>
<dd>Tendency to underestimate the amount of time to complete a project when it is "nearly done"</dd>
<dt>Overengineering</dt>
<dd>Spending resources making a project more robust and complex than is needed</dd>
<dt>Scope creep</dt>
<dd>Uncontrolled changes or continuous growth in a project's scope, or adding new features to the project
after
the original requirements have been drafted and accepted (also known as requirement creep and feature creep)
</dd>
<dt>Smoke and mirrors</dt>
<dd>Demonstrating unimplemented functions as if they were already implemented</dd>
<dt>Brooks's law</dt>
<dd>Adding more resources to a project to increase velocity, when the project is already slowed down by
coordination overhead.</dd>
</dl>
</section>
</article>
<article>
<h1>Principles</h1>
<section>
<h2>SOLID</h2>
<dl>
<dt>Single Responsibility Principle (SRP)</dt>
<dd>class should have single responsibility</dd>
<dd>class shoud have one, and only one, reason to change</dd>
<dt>Open/Closed Principle (OCP)</dt>
<dd>class should be open for extension, but closed for modification</dd>
<dt>Liskov substition principle (LSP)</dt>
<dd>object should be replacable by instances of their subtypes without altering the correctness of that
programm</dd>
<dt>Interface Segregation Principle (ISP)</dt>
<dd>many client specific interfaces better then one general purpose interface</dd>
<dt>Dependency Inversion Principle (DIP)</dt>
<dd>one should depend upon asbtraction not conretion</dd>
</dl>
</section>
<section>
<h2>GRASP</h2>
<p>General responsibility assignment software patterns</p>
<dl>
<dt>Controller</dt>
<dd>Controller is responsible for receiving or handling a system event</dd>
<dt>Creator</dt>
<dd>Creator is responsible for creating objects</dd>
<dd>- contain or compositely aggregate instances</dd>
<dd>- record or closely use instances</dd>
<dd>- have initializing information for instances</dd>
<dt>High cohesion</dt>
<dd>Responsibility are strongly related and highly focused</dd>
<dt>Indirection</dt>
<dd>Assign the responsibility of mediation between two elements to an intermediate object</dd>
<dt>Information expert</dt>
<dd>Assign the responsibility to the class which has the information neccessary to fulfill that responsibility
</dd>
<dt>Low coupling</dt>
<dd>Assign responsibilities to support lower dependency between classes, change in one class having lower
impact on other classes, higher reuse potential</dd>
<dt>Polimorphism</dt>
<dd>Assign a responsibility according to the type of variation of behaviors by polymorphic operations</dd>
<dt>Protected variation</dt>
<dd>Protects elements from variations on others by wrapping into interface and using polymorphism</dd>
<dt>Pure fabrication</dt>
<dd>Specially made class to archieve low coupling, high cohesion and reuse potential</dd>
</dl>
</section>
<section>
<h2>YARGNI</h2>
<p>You aren't gone need it`</p>
</section>
<section>
<h2>KISS</h2>
<p>Keep it short and simple</p>
</section>
<section>
<h2>DRY</h2>
<p>Don't repeat your self</p>
</section>
<section>
<h2>Hollywood Principle</h2>
<p>Don’t Call Us, We’ll Call You.</p>
</section>
<section>
<h2>Ocam's razor</h2>
<p>Entities should not be multiplied without necessity. When presented with competing hypotheses that make the
same predictions, one should select the solution with the fewest assumptions, and it is not meant to be a way
of choosing between hypotheses that make different predictions</p>
</section>
<section>
<h2>SSOT (single source of truth)</h2>
<p>Single source of truth (SSOT) is the practice of structuring information models and associated data schema
such that every data element is mastered (or edited) in only one place</p>
</section>
</article>
<article>
<h1>Patterns</h1>
<section>
<h2>Creatinal patterns</h2>
<dl>
<dt>Abstract factory</dt>
<dt>Builder</dt>
<dt>Factory method</dt>
<dt>Lazy initialization (virtual proxy)</dt>
<dt>Multiton</dt>
<dt>Object library</dt>
<dt>Object pool</dt>
<dt>Prototype</dt>
<dt>Resource acquisitino is initialization (RAII)</dt>
<dt>Singleton</dt>
</dl>
</section>
<section>
<h2>Behaviral patterns</h2>
<dl>
<dt>Blackboard</dt>
<dt>Chain of responsibility</dt>
<dt>Command</dt>
<dt>Interpreter</dt>
<dt>Interator</dt>
<dt>Mediator</dt>
<dt>Memento</dt>
<dt>Null object</dt>
<dt>Observer or Publish/Subscrube</dt>
<dt>Servant</dt>
<dt>Specification</dt>
<dt>State</dt>
<dt>Strategy</dt>
<dt>Template method</dt>
<dt>Visitor</dt>
</dl>
</section>
<section>
<h2>Structural patterns</h2>
<dl>
<dt>Adapter, Wrapper or Translator</dt>
<dt>Bridge</dt>
<dt>Composite</dt>
<dt>Decorator</dt>
<dt>Facade</dt>
<dt>Flyweight</dt>
<dt>Front controller</dt>
<dt>Marker</dt>
<dt>Module</dt>
<dt>Proxy</dt>
<dt>Twin</dt>
</dl>
</section>
<section>
<h2>Concurency patterns</h2>
<dl>
<dt>Active object</dt>
<dt>Balking</dt>
<dt>Binding properties</dt>
<dt>Double-checked locking</dt>
<dt>Event-based asynchrones</dt>
<dt>Guarded suspension</dt>
<dt>Join</dt>
<dt>Lock</dt>
<dt>Messaging desing pattern (MDP)</dt>
<dt>Monitor object</dt>
<dt>Reactor</dt>
<dt>Read-write lock</dt>
<dt>Scheduler</dt>
<dt>Thread pool</dt>
<dt>Thread specific storage</dt>
</dl>
</section>
<section>
<h2>Anti-Patterns</h2>
<h3>Software design</h3>
<dl>
<dt>Abstraction inversion</dt>
<dd>Not exposing implemented functionality required by callers of a function/method/constructor, so that the
calling code awkwardly re-implements the same functionality in terms of those calls</dd>
<dt>Ambiguous viewpoint</dt>
<dd>Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
</dd>
<dt>Big ball of mud</dt>
<dd>A system with no recognizable structure</dd>
<dt>Database-as-IPC</dt>
<dd>Using a database as the message queue for routine interprocess communication where a much more lightweight
mechanism would be suitable</dd>
<dt>Gold plating</dt>
<dd>Continuing to work on a task or project well past the point at which extra effort is not adding value</dd>
<dt>Inner-platform effect</dt>
<dd>A system so customizable as to become a poor replica of the software development platform</dd>
<dt>Input kludge</dt>
<dd>Failing to specify and implement the handling of possibly invalid input</dd>
<dt>Interface bloat</dt>
<dd>Making an interface so powerful that it is extremely difficult to implement</dd>
<dt>Magic pushbutton</dt>
<dd>A form with no dynamic validation or input assistance, such as dropdowns</dd>
<dt>Race hazard</dt>
<dd>Failing to see the consequences of events that can sometimes interfere with each other</dd>
<dt>Stovepipe system</dt>
<dd>A barely maintainable assemblage of ill-related components</dd>
</dl>
<h3>Object-oriented programming</h3>
<dl>
<dt>Anemic domain model</dt>
<dd>The use of the domain model without any business logic. The domain model's objects cannot guarantee their
correctness at any moment, because their validation and mutation logic is placed somewhere outside (most
likely in multiple places). Martin Fowler considers this to be an anti-pattern, but some disagree that it is
always an anti-pattern.[6]</dd>
<dt>Call super</dt>
<dd>Requiring subclasses to call a superclass's overridden method</dd>
<dt>Circle–ellipse problem</dt>
<dd>Subtyping variable-types on the basis of value-subtypes</dd>
<dt>Circular dependency</dt>
<dd>Introducing unnecessary direct or indirect mutual dependencies between objects or software modules</dd>
<dt>Constant interface</dt>
<dd>Using interfaces to define constants</dd>
<dt>God object</dt>
<dd>Concentrating too many functions in a single part of the design (class)</dd>
<dt>Object cesspool</dt>
<dd>Reusing objects whose state does not conform to the (possibly implicit) contract for re-use</dd>
<dt>Object orgy</dt>
<dd>Failing to properly encapsulate objects permitting unrestricted access to their internals</dd>
<dt>Poltergeists</dt>
<dd>Objects whose sole purpose is to pass information to another object</dd>
<dt>Sequential coupling</dt>
<dd>A class that requires its methods to be called in a particular order</dd>
<dt>Yo-yo problem</dt>
<dd>A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation</dd>
</dl>
<h3>Programming</h3>
<dl>
<dt>Accidental complexity</dt>
<dd>Programming tasks which could be eliminated with better tools (as opposed to essential complexity inherent
in the problem being solved)</dd>
<dt>Action at a distance</dt>
<dd>Unexpected interaction between widely separated parts of a system</dd>
<dt>Boat anchor</dt>
<dd>Retaining a part of a system that no longer has any use</dd>
<dt>Busy waiting</dt>
<dd>Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
</dd>
<dt>Caching failure</dt>
<dd>Forgetting to clear a cache that holds a negative result (error) after the error condition has been
corrected</dd>
<dt>Cargo cult programming</dt>
<dd>Using patterns and methods without understanding why</dd>
<dt>Coding by exception</dt>
<dd>Adding new code to handle each special case as it is recognized</dd>
<dt>Design pattern</dt>
<dd>The use of patterns has itself been called an anti-pattern, a sign that a system is not employing enough
abstraction[7]</dd>
<dt>Error hiding</dt>
<dd>Catching an error message before it can be shown to the user and either showing nothing or showing a
meaningless message. This anti-pattern is also named Diaper Pattern. Also can refer to erasing the Stack
trace
during exception handling, which can hamper debugging.</dd>
<dt>Hard code</dt>
<dd>Embedding assumptions about the environment of a system in its implementation</dd>
<dt>Lasagna code</dt>
<dd>Programs whose structure consists of too many layers of inheritance</dd>
<dt>Lava flow</dt>
<dd>Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has
unpredictable consequences[8][9]</dd>
<dt>Loop-switch sequence</dt>
<dd>Encoding a set of sequential steps using a switch within a loop statement</dd>
<dt>Magic numbers</dt>
<dd>Including unexplained numbers in algorithms</dd>
<dt>Magic strings</dt>
<dd>Implementing presumably unlikely input scenarios, such as comparisons with very specific strings, to mask
functionality.</dd>
<dt>Repeating yourself</dt>
<dd>Writing code which contains repetitive patterns and substrings over again; avoid with once and only once
(abstraction principle)</dd>
<dt>Shooting the messenger</dt>
<dd>Throwing exceptions from the scope of a plugin or subscriber in response to legitimate input, especially
when this causes the outer scope to fail.</dd>
<dt>Shotgun surgery</dt>
<dd>Developer adds features to an application codebase which span a multiplicity of implementors or
implementations in a single change</dd>
<dt>Soft code</dt>
<dd>Storing business logic in configuration files rather than source code[10]</dd>
<dt>Spaghetti code</dt>
<dd>Programs whose structure is barely comprehensible, especially because of misuse of code structures</dd>
</dl>
<h3>Methodological</h3>
<dl>
<dt>Copy and paste programming</dt>
<dd>Copying (and modifying) existing code rather than creating generic solutions</dd>
<dt>Every Fool Their Own Tool</dt>
<dd>Failing to use proper software development principles when creating tools to facilitate the software
development process itself.[11][original research?]</dd>
<dt>Golden hammer</dt>
<dd>Assuming that a favorite solution is universally applicable (See Silver bullet)</dd>
<dt>Improbability factor</dt>
<dd>Assuming that it is improbable that a known error will occur</dd>
<dt>Invented here</dt>
<dd>The tendency towards dismissing any innovation or less than trivial solution originating from inside the
organization, usually because of lack of confidence in the staff</dd>
<dt>Not Invented Here (NIH) syndrome</dt>
<dd>The tendency towards reinventing the wheel (failing to adopt an existing, adequate solution)</dd>
<dt>Premature optimization</dt>
<dd>Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even
real-world efficiency</dd>
<dt>Programming by permutation / accident / coincidence</dt>
<dd>Trying to approach a solution by successively modifying the code to see if it works</dd>
<dt>Reinventing the square wheel</dt>
<dd>Failing to adopt an existing solution and instead adopting a custom solution which performs much worse
than the existing one</dd>
<dt>Silver bullet</dt>
<dd>Assuming that a favorite technical solution can solve a larger process or problem</dd>
<dt>Tester Driven Development</dt>
<dd>Software projects in which new requirements are specified in bug reports</dd>
</dl>
</section>
</article>
<article>
<h1>DataBase</h1>
<section>
<h2>ACID</h2>
<dl>
<dt>Atomicity</dt>
<dd>Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is
treated as a single "unit", which either succeeds completely, or fails completely: if any of the statements
constituting a transaction fails to complete, the entire transaction fails and the database is left
unchanged.</dd>
<dt>Consistency</dt>
<dd>Consistency ensures that a transaction can only bring the database from one valid state to another,
maintaining database invariants: any data written to the database must be valid according to all defined
rules, including constraints, cascades, triggers, and any combination thereof.</dd>
<dt>Isolation</dt>
<dd>Isolation ensures that concurrent execution of transactions leaves the database in the same state that
would have been obtained if the transactions were executed sequentially. Isolation is the main goal of
concurrency control; depending on the method used, the effects of an incomplete transaction might not even
be visible to other transactions.</dd>
<dt>Durability</dt>
<dd>Durability guarantees that once a transaction has been committed, it will remain committed even in the
case of a system failure.</dd>
</dl>
</section>
<section>
<h2>CAP theorem</h2>
<p>It is imposible for distributed data store to simultaneously provide more than two of the:
<strong>Consistency, Availability, Partition tolerance</strong></p>
<dl>
<dt>Consistency</dt>
<dd>all clients see the same data at the same time</dd>
<dt>Availability</dt>
<dd>the system continues to operate even in the presence of node failures</dd>
<dt>Partition tolerance</dt>
<dd>the system continues to operate inspite of network failure</dd>
</dl>
</section>
<section>
<h2></h2>
<dl>
<dt>Multiversion concurrency control (MCC or MVCC)</dt>
<dd>
Without concurrency control, if someone is reading from a database at the same time as someone else is
writing to it, it is possible that the reader will see a half-written or inconsistent piece of data.
MVCC aims at solving the problem by keeping multiple copies of each data item. In this way, each user
connected to the database sees a snapshot of the database at a particular instant in time. Any changes made
by a writer will not be seen by other users of the database until the changes have been completed (or, in
database terms: until the transaction has been committed.)
When an MVCC database needs to update a piece of data, it will not overwrite the original data item with new
data, but instead creates a newer version of the data item. Thus there are multiple versions stored. The
version that each transaction sees depends on the isolation level implemented. The most common isolation
level implemented with MVCC is snapshot isolation. With snapshot isolation, a transaction observes a state
of the data as when the transaction started. MVCC introduces the challenge of how to remove versions that
become obsolete and will never be read. In some cases, a process to periodically sweep through and delete
the obsolete versions is implemented. This is often a stop-the-world process that traverses a whole table
and rewrites it with the last version of each data item.
</dd>
</dl>
</section>
<section>
<h2>Isolation levels</h2>
<dl>
<dt>read uncommitted</dt>
<dd>dirty read</dd>
<dt>read committed</dt>
<dd>non repeatable read</dd>
<dt>repeatable read</dt>
<dd>phantom read</dd>
<dt>serializable</dt>
</dl>
</section>
<section>
<h2>Normal forms</h2>
<dl>
<dt>UNF: Unnormalized form</dt>
<dd></dd>
<dt>1NF: First normal form</dt>
<dd>To satisfy 1NF, the values in each column of a table must be atomic.</dd>
<dt>2NF: Second normal form</dt>
<dd>To conform to 2NF and remove duplicities, every non-key attribute must depend on the whole key, not just
part of it. </dd>
<dt>3NF: Third normal form</dt>
<dd>A table in third normal form (3NF) is a table in 2NF that has no transitive dependencies. No non-prime
(non-key) attribute is transitively dependent on any key i.e. no non-prime attribute depends on other
non-prime attributes. All the non-prime attributes must depend only on the keys.</dd>
<dt>EKNF: Elementary key normal form</dt>
<dd>The elementary key normal form (EKNF) falls strictly between 3NF and BCNF and is not much discussed in the
literature. It is intended “to capture the salient qualities of both 3NF and BCNF” while avoiding the
problems of both (namely, that 3NF is “too forgiving” and BCNF is “prone to computational complexity”).</dd>
<dt>BCNF: Boyce–Codd normal form</dt>
<dd>
A relational schema R is considered to be in Boyce–Codd normal form (BCNF) if, for every one of its
dependencies X → Y, one of the following conditions hold true:<br />
- X → Y is a trivial functional dependency (i.e., Y is a subset of X)<br />
- X is a superkey for schema R
</dd>
<dt>4NF: Fourth normal form</dt>
<dd> Whereas the second, third, and Boyce–Codd normal forms are concerned with functional dependencies, 4NF is
concerned with a more general type of dependency known as a multivalued dependency. A table is in 4NF if and
only if, for every one of its non-trivial multivalued dependencies X ↠ {\displaystyle \twoheadrightarrow }
\twoheadrightarrow Y, X is a superkey—that is, X is either a candidate key or a superset thereof.</dd>
<dt>ETNF: Essential tuple normal form</dt>
<dd></dd>
<dt>5NF: Fifth normal form</dt>
<dd>Fifth normal form (5NF), also known as project-join normal form (PJ/NF), is a level of database
normalization designed to reduce redundancy in relational databases recording multi-valued facts by
isolating semantically related multiple relationships. A table is said to be in the 5NF if and only if every
non-trivial join dependency in that table is implied by the candidate keys. A join dependency *{A, B, … Z}
on R is implied by the candidate key(s) of R if and only if each of A, B, …, Z is a superkey for R.[1] </dd>
<dt>DKNF: Domain-key normal form</dt>
<dd>Domain-key normal form (DK/NF) is a normal form used in database normalization which requires that the
database contains no constraints other than domain constraints and key constraints. A domain constraint
specifies the permissible values for a given attribute, while a key constraint specifies the attributes that
uniquely identify a row in a given table. The domain/key normal form is achieved when every constraint on
the relation is a logical consequence of the definition of keys and domains, and enforcing key and domain
restraints and conditions causes all constraints to be met. Thus, it avoids all non-temporal anomalies.</dd>
<dt>6NF: Sixth normal form</dt>
<dd>A simple and intuitive definition of the sixth normal form is that "a table is in 6NF when the row