3. Overview
o About me
o Samuel Fonseca
o Work at Clear Creek
o Self-taught
o started to learn with my job at Clear Creek
o Discuss my first and last major project
o How the code evolved
o My first inspirations for the site’s structure
o Based file structure on Elementary OS’ Open Source Website project
o Researched what Student Applications looked like for other schools
o Had to learn how SONIS’, our student management system, API, worked
4. 01 Both the front end and the back end had to be built by me. There was no one
available to assist me in building any of the Application’s functions or its
implementation within the current flow of Admissions.
02 It had to be done within one summer - between May and August - ready for
testing and deployment during the fall semester for applications for the spring
semester.
03 My knowledge of PHP and JavaScript were limited when I began. I also had to
learn how to communicate with a complete separate system written in
ColdFusion through their provided API - which had almost NO documentation.
Three major roadblocks
How a one-man job can seem overwhelming
5. The complexity problem
o Programming is very complex
o My code had to work with the current flow of Admissions
o SONIS, the student management system, is less than ideal with
complex and patched code.
o Most of the code was encrypted
o Their documentation was less than ideal
o Front-end was even more complex
o Offer applicants an error-free experience
o A nice flowing process with intuitive design language
o Fast load times, with quick server responses and smooth
animations
o Browsers and screens sizes make everything 100x more difficult
o Compliance
o The Student Application manages a lot of sensitive data
o Any security holes could present a serious problem
6. Homebrew : The good / the bad
How writing my own code helped me
o Learned many basic concepts
o Databases
o HTTP queries
o RESTful API
o cURL
o Authentication
o Cookies & Sessions
o AJAX
o No previous experiences with most
of those items
o Handling POST/Responses from the
API
o Not efficient - since most of this was
new
Screens
Every website has to take in
consideration the different screens
and browsers which will use their
services
7. What building from the ground up taught me
Homebrew code taught
me to understand the
basic building blocks of
web applications
o Understanding how a server handles sessions
o Object-Oriented Code
o DRY Code
o SQL and database structures
o The difference between the front-end and back-
end
o Understanding server responses
8. Introduce LaravelIntroduce Laravel
Laravel is a web application framework with expressive,
elegant syntax. We believe development must be an
enjoyable and creative experience to be truly fulfilling.
Laravel attempts to take the pain out of development by
easing common tasks used in most web projects.
9. The decision to switch
o The project had become extremely
complex
o Used a lot of SQL
o Time consuming
o Prone to errors
o A lot of repeated code
o The project needed some changes to
its structure
o The front-end was limited for
expansions
o The back-end was a mess of
procedural and objective code
o Laravel offered the basic needed tools
o SQL abstraction helped decluarted
the code
o Starting from the beginning allowed
for a new approach
o Creating the application as a SPA
o Data redundancy
o The ability to expand functions
o Reliability
o Calls to the API are queued
o Cache of API deliever’s results faster
o Handling HTTP Error responses (400,
500, etc)
10. Laravel : The good / the bad
Laravel opened the doors for a whole new level of development
o Applied previous principles within the
framework
o A routable RESTful API
o SPA
o VueJS
o Vue Router
o Vuex
o Better authentication
o Database abstraction
o LDAP support
o Cached and queued communication
with SONIS API
o User Web Notifications
o Laravel makes those much easier
o Specially PDO database
abstractions
Screens
Every website has to take in
consideration the different screens
and browsers which will use their
services
11. How Laravel empowered me
The framework
introduced tools
that takes care of
the basics
o Data Abstractions
o Notifications & Mail
templates
o Routing
o Web via VueJS
Router
o API via Laravel
o Proper HTTP Responses
o Response codes
o Using JavaScripts
Promises
o Better error throwing &
catching
12. Takeaways: A production-level application
o Beginners should not begin their journey with a framework
o Bad code taught me
o How SQL and the server code interact with one another
o SQL Table’s structures
o Relationships
o Understanding the importance of data structure
o Data Types
o Basics of Objects and their relationships
o Class instances
o Object inheritance
o There is value in bootstrapping without a framework
o Development time went from a bit over 4 months; to just about a month and a half
13. Takeaways (continued)
o Frameworks are not for all projects
o Consider this
This is the basic principle of a framework: Not having to
reinvent the wheel. And doing away with foreboding, low value
added tasks (for example, the development of generic
components) in order to fully focus on the business rules.
As an example, a framework will keep the developer from
having to spend 2 or 3 days creating an authentication form
(which is not a specific task). The time that is saved can be
dedicated to more specific components as well as to the
corresponding unit tests; giving you solid, sustainable and high
quality code.1
DoubleClick by Google found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load.
https://developers.google.com/web/fundamentals/performance/why-performance-matters