idodin

Dynamic Programming Patterns and Tricks

A couple of quick notes before summarizing some common Dynamic Programming Patterns, how to recognize them and how their recurrence relations work:

• Do not memorize patterns to get good at DP. Have them as reference points in your head in case your stuck.
• Always think of DP as an afterthought after thinking how a problem can be solved recursively (i.e. think of the "Optimal Substructure" property first and then use DP to reduce redundant work from the "Overlapping Subproblems")
• The intuition for DP comes from the Top-Down appraoch of thinking of it (i.e. the "Optimal Substructure) - Bottom Up approaches are optimizations. You should explain your solution with Top-Down logic, even if you want to eventually optimize with Bottom-Up.

When explaining DP solutions:

• Use appropriate terminology - refering to states, transitions, recurrence relations etc. will make it a lot easier for interviewers to follow your reasoning.
• Clearly state your recurrence relation / lo

idodin

Inheritance

We want to avoid reusing things in code, Inheritance allows us to extend a class definition, keeping everything that was defined in a parent class and optionally adding some more fields / methods to a child class.

class Dog {
  private int age;
  private int weight; 
  private String color;
 private String name; 

idodin

import java.util.*;
import java.math.*;
import java.io.*;

public class Main {
  public static void main(String[] args) throws Exception {
    BufferedReader br = new BufferedReader(
      new InputStreamReader(System.in)
    );
    StringTokenizer st = new StringTokenizer(br.readLine());

idodin

apply plugin: 'java'
apply plugin: 'application'
//apply plugin: 'junit-platform-gradle-plugin'
sourceCompatibility = 8
targetCompatibility = 8

// Versioning of dependencies
wrapper.gradleVersion = '5.6.2'

repositories {

idodin

Open Source Release Pipeline Issues

Hacktoberfest

Learn more about Hacktoberfest here (Free t-shirt / stickers)

Caverna

An Android App for Scoring Games of "Caverna - The Cave Farmers"

idodin

Software Language Engineering Core Concept Recap

OMG's Model-Driven Architecture

OMG - Object Management Group. They made a proposal called MDA (Model-Driven Architecture) to use Model-Driven Engineering to Systems Development. Model-Driven Engineering - Use models for code generation, verification etc. Not just as a way of exchanging information with other engineers.

Four Principles of MDA

• Models must be expressed in a well-defined notation - i.e. a definition must exist for the model so everyone knows what the model is saying.
• System specs must be organized around a set of models and associated transformations - mappings and relations between multi-layered models.

idodin

Week 1 Problem Sets

CodeForces

• CodeForces 1104B: Game with String
• CodeForces 1100B: Building a Contest
• CodeForces 702B: Powers of Two
• CodeForces 1007A: Reorder the Array
• CodeForces 1006C: Three Parts of the Array
• CodeForces 1041C: Coffee Break
• CodeForces 18C: Stripe

idodin

MIAE Pamphlet / Industry Dinner Design Update:

Stretched MIAE Logo

Easy peasy. Just adjust the logo until it looks nice.

Change font.

I changed to a couple of different fonts that are known for being clear:

• Acumin Variable Concept (Currently selected)
• Myriad Variable Concept
• PT Sans

idodin

First Demo Code

package myPackage;

import lejos.hardware.ev3.LocalEV3;
import lejos.hardware.motor.Motor;
import lejos.hardware.port.Port;
import lejos.hardware.sensor.EV3TouchSensor;
import lejos.hardware.sensor.SensorModes;

idodin

Continous Integration for the Sleepy 💤 😴

Hey and welcome to my short gist explaining the basics of Continous Builds and Continuous Integration and how they fit into the Software Development Lifecycle!

Continous Integration and the Software Development Life Cycle

This section aims to give users a brief introduction to the Software Development Life Cycle (SDLC) and explain Continuous Integration's placement within this Life Cycle.

How does CI fit into the Software Development Life Cycle?

CI really concerns the last 3 phases of the cycle outlined below. The idea is that, when we add something to our codebase, it could break our codebase :(. In order to prevent this, we execute automated tests and rebuild our system whenever new code is added to the codebase. These tests and builds should check whether our System is still working as a whole. If it isn't we want to alert the development team so they know to fix something and not merge these changes into another branch !!!.

Intr