All posts by Richard Herz

My advice to students for succeeding at the university

Interactive Learning, Uncategorized

1) Study with at least one other student in each class. Get study buddies.

Don’t do it all alone. You will learn from other students, even when you show them how you figured things out. They will keep you honest when studying for a test: no peeking at notes when they ask a potential test question.

2) Schedule plenty of time to study and do homework. Do not overcommit.

Do not get too involved with work, student organizations, athletics, gaming, or partying. There are lots of interesting things to do at the university other than study.

Note: Not following (1) and (2) are almost always the reasons I have seen students struggle at UCSD. Everyone who gets admitted is smart enough. Don’t worry about that.

3) Talk to your professors and TAs.

A couple times during the term, ask them about topics in class or their research.

Do not always ask them about points on homework and tests. That will leave a negative impression of you. It is fine to ask about points, just not as the first question nor the only question.

At their office door, always remind them of your name, and ask them if they have a minute to talk about (fill in something interesting, not points). Do not ask, “are you busy?” Stupid question. Prof’s are always busy! Best not to approach them right before class.

Don’t wait until you are struggling in a class. Always talk to them if you do start to struggle for any reason, even if you haven’t talked to them before. Get help early!

If they know you, then you are more likely to get “the benefit of the doubt” during grading, e.g., drawing the grade line just below you instead of just above you.

4) Aim for A grades. Try to get at least B grades.

To keep open the option of going to grad school or professional school, you need to graduate with at least a 3.0 GPA overall. Also, you need at least 3.0 (B) average in your major if you want to continue in that major in grad school.

Most schools won’t admit a student to grad school with less than a 3.0 GPA, except in unusual, extenuating circumstances and with a sponsoring professor. Don’t rely on that. With less than a 3.0, your options are schools with lower standards, lower reputations, and higher costs.

5) The day before your first day of class, walk around campus and locate your classrooms.

Before serving on an advising panel one day, I asked a barista at Muir Woods the most important thing to tell new students. This is her advice. Sounds good to me.

Fun to see Visitor Maps

Web Site

We recently added the Visitor Maps plugin to our About page. We are getting about 50 visitors per day. By clicking the “View more maps in the Visitor Map Viewer” link under the map, you can get versions where you can mouse over the map pins, wait, and get a tool tip showing where the pin is located. Here is a static screen shot:

visitorMap
static screenshot of Visitor Map on Aug 12, 2016

Flow-based programming

Flow-based programming, Software Development

I recently discovered the Now page and work of Henri Bergius on flow-based programming (FBP). He is developer of NoFlo and lead developer of FLowhub. NoFlo (node.js flow…) is a Javascript tool for FBP, and Flowhub is a graphical development environment for FBP. FBP was invented in the late 1960’s at IBM by J. Paul Morrison.

FBP makes a lot of sense. As far as application-specific apps, see the chemical process simulators COCO, Aspen Plus, and even Reactor Lab’s Division 1, Lab 6, Reactor Networks. Although lacking a graphical programming interface, our web apps have code structured with a similar metaphor of independent objects sending messages to each other, as do the dynamic simulations in Reactor Lab. This metaphor makes writing, expanding, and maintaining dynamic simulations easy.

A screenshot of Reactor Lab’s Reactor Networks is shown here, with a screenshot from the Flowhub clock example below it. Click on an image to see full-sized version.

RL-reactor-networks

flowhub-clock

Web app experiment 3 posted – control of reactor T

Chemical Reaction Engineering, Dynamics, HTML5

Web app experiment 3 demonstrates feedback control of temperature during reaction in a continuous stirred tank reactor (CSTR). See the Resources tab, Web app experiments. Below is a static screenshot – click to enlarge.

web_app_3_image_4

At default conditions in manual control mode with constant inputs, the system oscillates. Do you know why the system oscillates? See the Resources tab, CRE Notes, 15 – CSTR thermal effects. Then put the system into Auto Control mode.

Web app development progress

HTML5

We are making progress in developing web apps using HTML5 technologies – Javascript and CSS. We have one HTML5 web app posted and are continuing to revise it as we develop our approach. See Web app experiments under the Resources tab.

The architecture we are using is that of separate code objects, representing separate process units, which send messages to each other. This architecture allows us to change a simulation easily by adding or subtracting units from a system model.

These dynamic simulations solve a set of coupled, first-order, ordinary differential equations. This type of system is termed an “initial value problem.” The solution method is stepping in time (the independent variable here) using the Euler method. The Euler method has inherent numerical errors, as do other numerical methods, but the solutions can be corrected to approach the exact solution, as we have done in several labs in the desktop Reactor Lab.

LiveCode apps on the web – loading speed may improve dramatically

HTML5, LiveCode

Experiments by others show that the speed at which LiveCode web apps load can be made much faster through several techniques. In my first experiment, the files loaded to the Western US from the LiveCode server in France. Putting the large files, which are common to all LiveCode web apps, on CDN’s (Content Delivery Networks), which post copies on servers around the world, may speed loading dramatically. Other techniques may include loading only the parts of the modular LiveCode engine that are needed for a specific app.

See work by [-hh] at the LiveCode Forums and click the link “test it here” on that post.

Initial impressions – HTML5 vs. LiveCode

HTML5, LiveCode

The Reactor Lab desktop app is built with LiveCode, a cross-platform rapid application development tool. In the Resources, Web app experiments section of this site, we are experimenting with HTML5 technologies – Javascript and CSS – to make interactive web apps. Here are some initial impressions.

HTML5 web apps have the advantage of cross-platform deployment – of a single set of files – on all platforms (operating systems) via web browsers. Web apps don’t have all the functionality of desktop apps and smart phone apps but they do have the main functionality we are looking for. LiveCode has cross-platform deployment on the desktop and as smart phone apps but you have to build and deploy a separate distribution for each platform. Web deployment is under development in LiveCode version 8 but our initial experiments show that loading the first app is slow: about 40 s currently in my browser in California fetching the page from the server in France, where load times increase with distance from the server. But this is a development version of LC 8 and speeds may improve in the future. In contrast, HTML5 web apps are small and load fast.

Layout of LiveCode screens (“cards”) is easy and fast. Just drag and drop both active (e.g., buttons and widgets) and graphical elements. You can easily change the appearance and locations of elements with script when the app is running – so far it seems more easily than in HTML5. For HTML5 apps, we are using the desktop tool MACAW. In that tool, you can also drag and drop elements onto a page, then generate HTML and CSS files but not nearly as easily as LiveCode.

LiveCode is programmed with a very high level, English-like language that is easy to learn. Code (scripts) can be embedded in objects on the screen (e.g., buttons) or placed at a top level (card, stack). Proprietary code can be encrypted in the paid version. HTML5 web apps are programmed with Javascript. We have found Javascript easy to learn, although we have been programming for 50 years in a dozen languages, so we can’t say how easy it will be for a novice. The site w3schools.com is a great resource for learning Javascript, as well as HTML and CSS. Javascript is not attached to individual screen elements but placed at a top level, either in a script tag in the HTML file or, better, in a separate JS file. We haven’t tried text handling in Javascript but text handling in LiveCode is super easy.

Bottom line of initial impressions? LiveCode wins in ease of development and power. HTML5 wins in deployment – one set of files across all platforms – and speed of loading. We are leaning to devoting our efforts for future development to HTML5, although we are going to keep an eye on LiveCode to see if the speed of loading web apps improves significantly.

Progress on web apps

HTML5, Resources

We are making progress in learning HTML5 technologies – Javascript and CSS – to make interactive web apps. Web app experiment 1, in the Resources section of this site, has been updated to feedback control of water level in a tank. We used the desktop app MACAW to graphically layout the main components of the web page and generate the HTML and CSS files.  Then we did some editing of the files generated by MACAW and added a link to our Javascript file.

We wrote the Javascript code ourselves. The Javascript code makes the web page interactive by getting user input, doing the computations, then updating the display. One thing we have discovered is that Javascript runs very fast in today’s browsers. Many years ago we compared the speed of computation of Javascript to some other languages and found it very slow. That situation has changed dramatically.

We are pretty happy with MACAW. It definitely speeds up the process of learning CSS and laying out a web page.  One very nice thing is that it generates standalone HTML and CSS files – you do NOT have to link your site to a proprietary library.