C U T B H P N

Final Project - Technology Presentations

Web Resources:

Linux Tutorials eclipse Code Project SysInternals Best SysInternals Tools Dr. Dobb's Journal Windows Forms COM at MSDN IDL Language base MIDL types OLE data types IDL attributes MIDL data types MIDL Language Reference

Content:

This page describes what is expected of your Technology Presentations.
  1. Syllabus
    Describes topics to be covered, reading material for you to digest before coming to class, and due dates for the assigned projects.
  2. Project #1, Project1HelpS16
    Final Projects

  3. Presentations:

    Technology Presentations, Probes Presentations, Final Presentations

  4. Final Project Presentation Schedule:

    Final Presentations Schedule, xlsx

  5. Presentation Topics:

    • Introduction (10 minutes)
      Describe your project and what you hope to accomplish. Please be specific. This part should constitute 20% to 30% of your presentation.
    • Describe the Technology (10 minutes)
      Present a tutorial on the technological basis for your project, e.g., HTTP, Asynchronous Processing, HTML5, ... For projects that include the Tiny HttpClient & HttpServer and MEAN stack website, there are other teams that do that too. Please try to work with other groups to avoid duplicating tutorial material. For example, there are several interesting things to discuss concerning HTTP, e.g., the basic messaging protocol, differences between HTTP 1.0 and 1.1, specific processing like chunking and encoding, the standard header information, etc. Each team can take one of these to present.
    • Project Tasks (7 minutes)
      Layout the tasks necessary to complete your project as you see them now.
    • Your Team (3 minutes)
      Describe how you and your team members will partition the Final Project's tasks.
    • How much time?
      I expect that a typical first presentation will take about 30 minutes. That's why I scheduled three presentations for each class. Our schedule is packed, so we can't reschedule presentations - that means you will have to strick strictly to the 30 minute time allotment. If you don't, I will stop you at the end of 30 minutes, and your grade will be based on what you present.
    • Content
      I encourage you to take some risks in what you set out to do. I would prefer to see you layout an ambitious project and not complete all of the tasks you describe in this first presentation, rather than being conservate and doing less challenging work.

  6. Forming Teams:

    • Final Project Mechanics:
      1. I will expect that a team will generate more content than a student that is not part of a team.
      2. If you are part of a team, in order to evaluate your work, each team member should be very clear and explicit about the part of the project they are working on. In some cases I may feel that an individual may not be developing enough content and I will assign additional things to look at and do.
      3. It is not unusual for one member of a team to play a smaller role than others for a specific presentation. That's O.K. as long as that team member takes a larger role in the other presentations (Technology, Probes, and Final).
  7. Suggestions for Projects:

    • MEAN Stack

      1. MongoDB is a noSQL database. It might be interesting to do a small comparison of MongoDB with other NoSql databases.
      2. Node.js is supposed to support very high performance messaging and Angular drives alot of website processing to the client. It would be interesting to compare the performance of an asp.net site with a MEAN site. This could be part of the probing examples, using small sites that do some significant, perhaps simulated, processing.
      3. References:
        MEAN Web Development - #1 of 9 articles
        JavaScript tutorial

    • REST Web Services

      Projects that use mobile apps will probably talk to RESTful web services.
      1. REST is a light-weight web service technology. It uses basic HTTP protocols without SOAP and RPC. The idea is to use the HTTP methods - GET, PUT, POST, and DELETE as the only actions supported, e.g., the verbs for interactions with the site. Objects acted on are described by URIs - Uniform Resource Identifiers.
      2. Many claim that REST is simpler, more obvious, more efficient, ...
      3. REST is not the same as a Web API. REST espouses one specific Web API - that of HTTP.
      4. REST projects for CSE775 - DO should try to use that specific model, using some interesting web service to illustrate its advantages and disadvantages.
      5. Refereces:
        Dr. Dobbs Tutorial
        REST - Wikipedia
        REST and .Net Web API
        REST with Asp.Net Web API

    • Cross-Platform Libraries

      1. The intent of the Cross-Platform Libraries project is to provide facilities for writing common code for both Windows and Linux applications. We do that by providing libraries implemented on both Windows and Linux that provide the same interface for applications to use.
      2. Here are some useful libraries:

        • FileSystem (already exists) that provides File, Path, and Directory facilities.
        • Concurrency: C++11 now provides, for both platforms:
          threads and locks
          BlockingQueues (my latest implementation is written in C++11)
          But more would be useful:
          light-weight locks based on Windows CriticalSection and Slim Reader/Writer lock - there are Linux equivalents
          Thread-Pool
          Task class (similar to .Net) I wrote a C++ Task class that uses a Thread-Pool, also implemented in C++. I think this will port with almost no effort to Linux, but there are a couple of features that you may decide to add or change (we can discuss this later).
        • Process Management:
          The intent is to create a Process class that is very similar to the .Net Process class. This is the most "interesting" part of a CP-Library.
        • Communication:
          sockets (Windows class exists - not yet ported to Linux)
          interprocess communication based on shared memory or named-pipes and Unix domain sockets
          message-passing (that's the topic for Tiny HTTP Client and Server project)
      3. Another interesting idea - Building a library container:

        • The container is a directory that contains an HTML5 web page with associated JavaScript (no asp.net please) and a subfolder for each of the libraries. Each library folder contains documentation and a zip containing the documentation, header file, a static library, a dynamic link library, and a source demonstration program. The implementer could also provide a zip with source code.
        • The web page provides access to the libraries, e.g.:
          1. Displays the directory for each library, FileSystem for example.
          2. Provides a link for documentation.
          3. Supports zip file download (you don't have to do anything for that - the browsers all support it).
        • For cross-platform development you would have two containers, one for Windows and one for Linux.
      4. References:
        IPC with Named Pipes
        C++ IPC wrapper for named pipes
        Unix Domain Sockets - Wedipedia
        Shared Memory on Windows - MSDN
        Shared Memory on Windows - Boost
        IPC using Shared Memory - CodeProject
        Shared Memory in Linux - cs.cr.ac.uk
        Shared Memory in Linux - makelinux.net
        Shared Memory - Wikipedia
        Beej's Guide to Network Programming - discusses Linux sockets

    • Cross-Platform GUI

      1. The intent of this project is to provide a facility for building GUI applications that is common to both Windows and Linux.
      2. We can do that by using the Chrome browser, HTML5, and Ajax along with a Tiny HTTP Server.

        • An application spawns a process running chrome, naming an HTML5 page with layout for the application's interface. The application writes JavaScript, downloaded with the HTML5 page, that reacts to interface events, like button clicks, with Ajax calls into the Tiny HTTP Server, hosted by the application.
        • The result is something like WPF, using HTML5 markup instead of Xaml and Javascript event handlers instead of C# handlers.
        • It would be very useful to develop a Javascript library, perhaps using jQuery, that makes it easier for application designers to build their interfaces.
      3. If we do all messaging between (Chrome) GUI using Ajax then Javascript does not get reloaded. That means that variable values will persist and our JavaScript begins to look like a real GUI processor.
      4. References:
        HTML5 - Wikipedia
        HTML5 - w3shools.com
        HTML5 - Mozilla.org
        Ajax - Mozilla.orgaja
        Ajax - Wikipedia

    • Tiny HTTP Client and Server

      1. The goal is to provide very small HTTP Client and Server packages. The intent is to support HTTP's synchronous request/reply process, but also to support one-way communication with HTTP messages where the client and server agree that the client won't wait for a reply.
      2. This project has obvious support for several of the other projects described here.
      3. References:
        HTTP Made Really Easy - A Practical Guide to Writing Clients and Servers - J.Marshall.com
        Apache HttpComponents

    • GO Programming Language

      1. Go is an interesting language much like the C language on steriods. It has built in concurrency, channels, and web servers. It's interesting that it does not provide classes. One possible direction to explore is to simulate classes using the struct and some libraries. That's how C++ started.
      2. It's important to explore the built-in concurrency, channels (similar to pipes, I believe), and other such facilities provided by the language.
      3. References:
        Go Programming Language - golang.org
        Go Programming - Wikipedia
        Introductory Tutorial

CST strip