diff --git a/pages/CSE332S/CSE332S_L16.md b/pages/CSE332S/CSE332S_L16.md
new file mode 100644
index 0000000..5620168
--- /dev/null
+++ b/pages/CSE332S/CSE332S_L16.md
@@ -0,0 +1,200 @@
+# CSE332S Lecture 16
+
+## Intro to OOP design and principles
+
+### Review: Class Design
+
+Designing a class to work well with the STL:
+
+- What operators are required of our class?
+  - `operator<` for ordered associative containers, `operator==` for unordered associative containers
+  - `operator<<` and `operator>>` for interacting with iostreams
+  - Algorithms require particular operators as well
+
+Designing a class that manages dynamic resources:
+
+- Must think about copy control
+  - **Shallow copy** or **deep copy**?
+  - When should the dynamic resources be cleaned up?
+  - Move semantics for efficiency
+
+### OOP Design: How do we combine objects to create complex software?
+
+Goals - Software should be:
+
+- Flexible
+- Extensible
+- Reusable
+
+Today: 4 Principles of object-oriented programming
+
+1. Encapsulation
+2. Abstraction
+3. Inheritance
+4. Polymorphism
+
+#### Review: Client Code, interface vs. implementation
+
+Today we will focus on a single class or family of classes related via a common
+base class and client code that interacts with it.
+
+Next time: Combining objects to create more powerful and complex objects
+
+**Client code**: code that has access to an object (via the object directly, a reference to the object, or a pointer/smart pointer to the object).
+
+- Knows an object’s public interface only, not its implementation.
+
+**Interface**: The set of all functions/operators (public member variables in C++ as well) a client can request of an object
+
+**Implementation**: The definition of an object’s interface. State (member variables) and definitions of member functions/operators
+
+#### Principle 1: Encapsulation
+
+Data and behaviors are encapsulated together behind an interface
+
+1. Member functions have direct access to the member variables of the object via “this”
+1. Benefit: Simplifies function calls (much smaller argument lists)
+
+Proper encapsulation:
+
+1. Data of a class remains internal (not enforced in C++)
+2. Client can only interact with the data of an object via its interface
+
+**Benefit**:
+
+(Flexible) Reduces impact of change - Easy to change how an object is stored
+without needing to modify client code that uses the object.
+
+#### Principle 2: Abstraction
+
+An object presents only the necessary interface to client code
+
+1. Hides unnecessary implementation details from the client  
+    a. Member functions that client code does not need should be private or protected
+
+We see abstraction everyday:
+
+- TV
+- Cell phone
+- Coffee machine
+
+Benefits:
+
+1. Reduces code complexity, makes an object easier to use
+2. (Flexible) Reduces impact of change - internal implementation details can be
+modified without modification to client code
+
+#### Principle 3: Inheritance (public inheritance in C++)
+
+**"Implementation" inheritance - class inherits interface and implementation of
+its base class**
+
+Benefits:
+
+- Remove redundant code by placing it in a common base class.
+- (Reusable) Easily extend a class to add new functionality.
+
+**"Interface" inheritance - inherit the interface of the base class only (abstract base class in C++, pure virtual functions)**
+
+Benefits:
+
+- Reduce dependencies between base/derived class
+- (Flexible, Extensible, Reusable) Program a client to depend on an interface rather than a specific implementation (more on this later)
+
+#### One More Useful C++ Construct: Multiple Inheritance
+
+C++ allows a class to inherit from more than one base class
+
+```cpp
+class Bear: public ZooAnimal {/*...*/};
+class Panda: public Bear, public Endangered {/*...*/};
+```
+
+Construction order - all base classes are constructed first:
+
+- all base classes -> derived classes member variables -> constructor body
+
+Destruction order - opposite of construction order:
+
+- Destructor body -> derived classes member variables -> all base class
+destructors
+
+**Rule of thumb**: When using multiple inheritance, a class should inherit
+implementation from a single base class only. Any number of interfaces may be
+inherited (this is enforced in Java)
+
+#### Principle 4: Polymorphism
+
+A single interface may have many different implementations (virtual functions and
+function overriding in C++)
+
+Benefits:
+
+1. Avoid nasty switch statements (function calls resolved dynamically)
+2. (Flexible) Allows the implementation of an interface to change at run-time
+
+#### Program to an interface
+
+Client should restrict variables to an interface only, not a specific implementation
+
+- **Extensible, reusable**: New subclasses that define the interface can be created and used without modification to the client. Easy to add new functionality. Easy to reuse client.
+- **Reduce impact of change**: Decouples client from concrete classes it uses.
+- **Flexible**: The implementation of an interface used by the client can change at run-time.
+
+In C++:
+
+- Abstract base class using pure virtual functions to declare the interface
+- Implement the interface in subclasses via public inheritance
+- Client maintains reference or pointer to the base class
+- Calls through the reference or pointer are polymorphic
+
+```cpp
+// declare printable interface
+class printable {
+    public:
+    virtual void print(ostream &o) = 0;
+};
+    // derived classes defines printable
+    // interface
+class smiley : public printable {
+    public:
+        virtual void print(ostream &o) {
+            o << ":)" ;
+        };
+};
+class frown : public printable {
+    public:
+    virtual void print(ostream &o) {
+        o << ":(";
+    };
+};
+int main(int argc, char * argv[]) {
+    smiley s; // s restricted to
+    // a smiley object
+    s.print();
+    // p may point to an object
+    // of any class that defines
+    // the printable interface
+    printable * p =
+    generateOutput();
+    // Client unaware of the
+    // implementation of print()
+    p->print();
+    return 0;
+}
+```
+
+Program to an interface
+Allows easily extensible designs: anything that defines the printable interface can
+be used with our client
+
+```cpp
+class Book : public printable {
+    vector<string> pages;
+    public:
+    virtual void print(ostream &o) {
+        for(unsigned int page = 0; page < pages.size(); ++page){
+            o << "page: " << page << endl;
+            o << pages[i] << endl;
+        };
+};
\ No newline at end of file
diff --git a/pages/Math4121/Math4121_L28.md b/pages/Math4121/Math4121_L28.md
index 3f89dbe..bd1212a 100644
--- a/pages/Math4121/Math4121_L28.md
+++ b/pages/Math4121/Math4121_L28.md
@@ -1 +1,120 @@
-# Lecture 28
\ No newline at end of file
+# Math4121 Lecture 28
+
+## Continue from last lecture
+
+### Lebesgue Measure
+
+#### Outer Measure
+
+$$
+m_e(S) = \inf_{S \subseteq \bigcup_{j=1}^{\infty} I_j} \sum_{j=1}^{\infty} \ell(I_j)
+$$
+
+If $S\subseteq I$ is measurable, then $m_i(S)=m_e(I)-m_e(I\setminus S)$
+
+#### Lebesgue criterion for measurability
+
+$S\subseteq I$ is measurable if and only if $m_e(I)=m_e(S)+m_e(I\setminus S)$
+
+#### Caratheodory's criteria
+
+Lebesgue criterion holds if and only if for any $X$ of finite outer measure,
+
+$$
+m_e(X)=m_e(X\cap S)+m_e(X\setminus S)
+$$
+
+> **Local additivity**
+>
+> $\{I_j\}_{j=1}^{\infty}$ is a collection of disjoint intervals, then 
+>
+> $$m_e\left(S\cap \bigcup_{j=1}^{\infty} I_j\right) = \sum_{j=1}^{\infty} m_e(S\cap I_j)$$
+> Proved on Friday
+
+Proof:
+
+$\implies$ If Lebesgue criterion holds for $S$, then for any $X$ of finite outer measure,
+
+$$
+m_e(X)=m_e(X\cap S)+m_e(X\setminus S)
+$$
+
+First, we extend Lebesgue criterion to intervals $I$ that may not contain $S$. Then we can find $J,K$ intervals neighboring $I$ such that $S\subseteq \tilde{I}=J\cup I\cup K$.
+
+By Lebesgue criterion,
+
+$$
+\begin{aligned}
+m_e(\tilde{I})&=m_e(\tilde{I}\cap S)+m_e(\tilde{I}\setminus S)\\
+&=m_e(S)+m_e(\tilde{I}\setminus S)\\
+&=m_e(S^c\cap \tilde{I})+m_e(S\cap \tilde{I})\\
+&=\sum_{L\in \{J,I,K\}}m_e(L\cap S^c)+m_e(L\cap S)\\
+&\geq \sum_{L\in \{J,I,K\}}m_e(L)\\
+&=m_e(\tilde{I})
+\end{aligned}
+$$
+
+Therefore, $m_e(I)=m_e(S^c\cap I)+m_e(S\cap I)$.
+
+Now, let $X$ has finite outer measure, let $\epsilon>0$, we can find $\{I_j\}_{j=1}^{\infty}$ covering $X$ and
+
+$$
+\sum_{j=1}^{\infty} \ell(I_j)<m_e(X)+\epsilon
+$$
+
+$$
+\begin{aligned}
+m_e(X)&\leq m_e(X\cap S)+m_e(S^c\cap X)\\
+&\leq m_e\left(\bigcup_{j=1}^{\infty} I_j\cap S\right)+m_e\left(\bigcup_{j=1}^{\infty} I_j\cap S^c\right)\\
+&\leq \sum_{j=1}^{\infty} m_e(I_j\cap S)+m_e(I_j\cap S^c)\\
+&=\sum_{j=1}^{\infty} m_e(I_j)\\
+&<m_e(X)+\epsilon
+\end{aligned}
+$$
+
+QED
+
+### Revisit Borel's criterion
+
+1. $m(I)=\ell(I)$
+2. If $\{S_j\}_{j=1}^{\infty}$ is a sequence of disjoint measurable sets, then $m\left(\bigcup_{j=1}^{\infty} S_j\right)=\sum_{j=1}^{\infty} m(S_j)$
+3. If $R\subseteq S$, then $m(S\setminus R)=m(S)-m(R)$
+
+#### Theorem 5.8 (Countable additivity for Lebesgue measure)
+
+If $\{S_j\}_{j=1}^{\infty}$ is a sequence of disjoint measurable sets, whose union $S=\bigcup_{j=1}^{\infty} S_j$,  has finite outer measure, then
+
+$$
+m_e(S)=\sum_{j=1}^{\infty} m_e(S_j)
+$$
+
+Proof:
+
+First we prove $m_e(\bigcup_{j=1}^{\infty} S_j)=\sum_{j=1}^{\infty} m(S_j)$ by induction.
+
+$n=1$ is trivial.
+
+Let $n>1$ and suppose the statement holds for $n-1$. Take $X=\bigcup_{j=1}^{n-1} S_j$, then $S_n\cap X=S_n, X\setminus S_n=\bigcup_{j=1}^{n-1} (S_j)$.
+
+By Caratheodory's criteria,
+
+$$
+\begin{aligned}
+m_e(X)&=m_e(S_n)+m_e(\bigcup_{j=1}^{n-1} S_j)\\
+m_e(\bigcup_{j=1}^{n} S_j)&=m(S_n)+\sum_{j=1}^{n-1} m(S_j)\\
+&=\sum_{j=1}^{n} m(S_j)
+\end{aligned}
+$$
+
+Take the limit as $n\to\infty$, and justify this.
+
+$\sum_{j=1}^{\infty} m(S_j)=m_e(\bigcup_{j=1}^{\infty} S_j)\leq m_e(S)$
+
+Since $m_e(S)$ is finite and $m(S_j)$ is monotone, the limit exists.
+
+Therefore, $\sum_{j=1}^{\infty} m(S_j)\leq m_e(S)\leq \sum_{j=1}^{\infty} m(S_j)$
+
+So $S$ is measurable.
+
+QED
+
diff --git a/pages/Math4121/_meta.js b/pages/Math4121/_meta.js
index 7f52165..0dc7d83 100644
--- a/pages/Math4121/_meta.js
+++ b/pages/Math4121/_meta.js
@@ -31,10 +31,6 @@ export default {
     Math4121_L25: "Introduction to Lebesgue Integration (Lecture 25)",
     Math4121_L26: "Introduction to Lebesgue Integration (Lecture 26)",
     Math4121_L27: "Introduction to Lebesgue Integration (Lecture 27)",
-    Math4121_L28: {
-        display: 'hidden'
-    },
-    Math4121_L29: {
-        display: 'hidden'
-    },
+    Math4121_L28: "Introduction to Lebesgue Integration (Lecture 28)",
+    Math4121_L29: "Introduction to Lebesgue Integration (Lecture 29)"
 }