Email Answer: Can you help me with my learning or one of your free / open classes that I am taking?

I get a number of messages per week from students who take my courses online.  I have well over a half million online students so I don’t have time to individually respond to all the messages I get via Twitter, Email, or LinkedIn.

I do skim all the messages I get – but only reply to a few.

Before I talk about the messages that I don’t answer, let me talk about the messages that I *do* answer like the following:

  • I am using an auto-grader in your course and it is broken.  If you have a screen shot where my code has an error message – I want to know about it and want to fix it.  I will bug you and ask you to keep testing the problem until I verify it is fixed.
  • If you find a typo or mistake in one of my web sites or books – I would like to hear about it.  I like to fix little things so the quality of the materials is kept high.
  • If you want to translate some of my course material to a new language – that is really cool and I want to hear about that.
  • You are a teacher and want to adopt or have used my materials for a course you are teaching.  I love that and want to hear about it.

The following types of messages are read – but I rarely reply to them:

  • Can you write a recommendation for me?  I only write recommendations for students I work with outside of class.  I don’t even write recommendations for students who take my courses on-campus at University of Michigan.   I *understand* that recommendations are difficult to get.  I just feel really bad writing a recommendation that says “I had Tony in class, and because he did not cause any trouble I would not even recognize Tony if he came up to me.”   I love writing recommendations for students when there is real collaboration.
  • Could you design a plan of study for me? Could you give me career advice?   I have some videos about career advice in some of my courses but don’t have time to be an individual career counselor.
  • Can you be my mentor?  I only mentor about 2-4 students per year – and I work with students because their interests (i.e. educational technology, open source, and open content) align with my interests and I get help from the students on my work.
  • Any question about Coursera, edX, or FutureLearn payments, dates, sessions, etc.   I provide my material to these MOOC platforms and they run the courses.  I don’t have veto power over what the platforms do or when the courses run or what the due dates are for each assignment.
  • Could you sign a certificate of attendance so I can get reimbursement?  This is an issue with the MOOC providers – I do not check ID nor take attendance in these courses so I can not and certify anything.
  • Any message about an honor code violation where you “mistakenly” uploaded something that was not your own work and you got caught.  These messages usually weave some long intricate story and want “one more chance” – I ignore these messages.   Read the assignments, do your own work and don’t take short cuts.
  • Can we connect on LinkedIn?  I only connect on LinkedIn to people I know professionally.  I don’t connect to students at all until I have worked with them on a project.

As I said above – I do see virtually every message and skim them all.  Sometimes something in a message will jump out at me.  Skimming a message is pretty quick but writing a reply takes a lot of time that I just don’t have.

It does not make me happy to ignore these messages – I wish I had time to reply to them all.  If I replied to every message it would take more time than I have in a day and I would get nothing done :(

So I apologize in advance.

-Chuck

 

 

 

 

How to build a JSR-168 Portlet in Sakai

Using JSR-168 portlets is the only way to have a page (like Overview) with multiple tools on the page rendered without iframes.  The portal only removes iframes when a page has one tool.  If there are > 1 tools – it uses iframes.   But JSR-168 tools never use iframes no matter how many there are on the page.

It is pretty easy to convert a servlet-style tool to portlet-style – in particular if the tool uses either JSP or Velocity templates, t is pretty simple.

Here is an example of a tool that uses Velocity:

https://github.com/sakaiproject/sakai/tree/master/web/web-portlet

https://github.com/sakaiproject/sakai/blob/master/web/web-portlet/src/java/org/sakaiproject/portlets/PortletIFrame.java

This was a direct conversion from an old iframe+servlet style tool used in earlier versions of Sakai:

https://github.com/sakaiproject/sakai/tree/master/web/web-tool

If you want to use JSP as your templating language, the following is a sample JSR-168 portlet:

https://github.com/sakaiproject/sakai/tree/master/basiclti/basiclti-portlet

https://github.com/sakaiproject/sakai/blob/master/basiclti/basiclti-portlet/src/java/org/sakaiproject/portlets/IMSBLTIPortlet.java

The portlet model sends GETs go to “view” methods and POSTs to “action” methods.  Our Velocity tools have the same concept of action and view – but they are hand-layered on top of a servlet using convention and classes like VelocityPortletPaneledAction so the pattern will be familiar for those who wander through old Sakai code.

Another interesting bit of Portlets is that they have view “modes” like “Help” and “Edit” that are part of the spec.  Velocity “portlets” have panels but they are not as formally defined.

For example if you see a JSR-168  portlet in Sakai (image)  (Home Information is a portlet) , there is a “Edit” button that comes from the *portal* in the portal title line.  That edit is not part of the portlet’s markup – the portlet simply declares one of its views as “the edit view” and Sakai puts up the button and wires it up.

For an old-school Velocity servlet pretending to be a portlet in an iframe (like Message of the in the image) the “edit mode” is just another panel in the tool and the tool puts out markup with a link to its “edit view” in “Options” below.

It is surprisingly easy to convert from the old to the new because the view/panel and action patterns already are pretty parallel – the velocity servlet that is a fake portlet was one of the inspirations for  JSR-168 so the similarity is not random.  Both were “cool” MVC approaches in 2001-2003.

I love the JSR-168 pattern for multiple independent rectangles on a page.  There is a clever pattern that allows all of the rectangles to handle the back button and refresh in a consistent manner for all three rectangles simultaneously.  I would love it if all the Sakai tools were rewritten as portlets – but with the magic iframe inlining since Sakai 11 – it is only really beneficial for synoptic tools.

Beyond an Accessible LMS – An Accessible LMS Community

TL;DR: Chris Knapp’s Post about two weeks of his experiences in the Sakai community

For over 15 years, the Sakai Learning Management System has been committed to building a product that not only meets the legal requirements of accessibility – but has the higher goal of making the Sakai user experience “excellent” for visually impaired learners.   We feel that an LMS must take that extra step because access to a good education is not a luxury – it is a fundamental human right.

Sakai greatly benefited from having Jutta Treviranus on our board during our early days.   Jutta helped us understand that accessibility for an LMS was not just a “checkbox”.  She not only inspired us to make Sakai a great product for visually impaired learners (i.e. all of us), she shared her research and innovation (i.e. https://idrc.ocadu.ca/ )  with us to give us the tools to achieve those goals.

Sakai is beginning an effort to take the next steps in becoming an accessible community.  Our goal is to make special efforts to being visually impaired contributors in as regular members of the community.  Our goal is for VI members to participate in all aspects of Sakai from development, to quality assurance and community leadership.  Of course one of their contributions will help us maintain the high standard for accessibility in the Sakai product – but our goals are broader than that.

My company (Learning Experiences) has retained Chris Knapp of Knapp Strategic to be embedded in the community and help us improve the accessibility of all of our processes and tools.   He will be integrated as part of the Sakai QA team (Chris is not a coder) and help us adapt all aspects of our human processes and/or tool chains to make them more accessible.

Once Chris works through how to be a visually impaired Sakai contributor, we will begin to recruit and Learning Experiences will pay other visually impaired people to be Sakai contributors.  We are just getting started with this but we have high hopes for the effort.

Chris wrote a blog post that summarizes his first few weeks of his involvement as a VI contributor in Sakai.

I will just say that it has been only a few weeks but has been great fun for me.  So far one of my favorite eye-opening moments was when Chris attended our weekly Marketing meeting.  We got to talking about an upcoming social media launch and we were talking about how images of the Sakaiger might be best used in the campaign.

Sitting in the Zoom meeting, I realized that Chris had absolutely no idea what the Sakaiger looked like.  And he had no idea even what the “rings of water” Sakai logo looked like.   So I sent him a stuffed Sakaiger and several knit caps with the Sakai “Jewel” logo on them.

A stuffed Sakaiger is an accessible three-dimensional version of a mascot image!  I never would have thought of that – except that once Chris was in a meeting with us – it was immediately obvious. Pretty cool.

 

 

 

Enabling a Just Education and Educational Technology Future

Enabling a Just Education and Educational Technology Future
PI: Dr. Charles R. Severance, University of Michigan School of Information
Unsolicited Funding Proposal – 2020-09

The Andrew W. Mellon Foundation support for the $2.4 million dollar Sakai Project to the University of Michigan and others in 2004, is probably the most impactful philanthropic investment in educational technology of all time.  The Sakai Project set out to solve the problems of software interoperability and data portability by developing an open source Learning Management system that would implement and demonstrate best practices to the educational technology industry.

In 2004 and 2005, by leveraging its Andrew W. Mellon Foundation support, Sakai quickly delivered on all three of its core goals.  We released four versions of Sakai (1.0, 1.5, 2.0, and 2.1). In late 2004, Sakai worked with IMS to form the IMS Tools Interoperability working group and in mid-2005, Sakai worked with IMS to form the IMS Common Cartridge Working Group.

Fifteen years later, these efforts have matured into an LMS market place committed to standards and interoperability.  When the latest version of IMS Learning Tools Interoperability (LTI Advantage) was released in 2019, five leading LMS vendors (Sakai, Moodle,  D2L,  Blackboard, and Canvas) announced support for the standard on the same day.

While the software interoperability efforts created by Sakai are a great success, there are larger concerns in the LMS and educational technology market that must be addressed to assure fair,  safe, and just access to education – particularly students in at-risk populations and for students outside the US/Europe:

  • At this point, 60% of the LMS marketplace is using proprietary cloud-only solutions owned by private-equity companies.  While these solutions are convenient for higher education, handing sensitive and private student activity data to these third parties who treat it as an asset is a concerning trend.
  • The lack of an open-source and standards-based learning object repository (LOR) continues to leave high quality material stuck in LMS systems.  When we reduce barriers to content reuse, we can broaden access to education regardless of geography or economic situation.
  • The lack of a MOOC platform that is interoperable, easy-to-use, and based on standards restricts MOOC-like approaches to the privileged, wealthy and proprietary.  None of the current MOOC platforms participate in educational technology standards activities.

The Sakai, Tsugi, and Apereo open source efforts will be able to achieve these goals with a reasonable level of investment.  Sakai is a mature LMS with some of the highest satisfaction ratings in the market, Tsugi is a simple, standards based learning object repository (LOR) and Massively Open Online Course (MOOC) hosting platform.  Tsugi has many technical aspects of LOR and LMS integration solved but so far has not had enough UI/UX investment to be used directly by a non-technical teacher.

Our open-source efforts are already working on these goals as fast as we can.  This proposal seeks funds to greatly accelerate efforts to (1) maximum protection of private student activity data, (2) standards and open source infrastructure to support reusable learning content, and (3) a MOOC platform that makes the creation and teaching of free and open educational experiences available to every teacher and student in the world.  It is a bold vision and we are well positioned to achieve these goals with sufficient resources.

Note: I wrote this as a response to an RFI with a goal of ensuring a Just Educational Future from an unnamed funding agency.  The RFI turned out to be aimed at an audience that did not include me so I  made it a blog post.  If any funding agency is interested in funding the work – let me know.  I am looking for about $5M over a three years period.

Infrastructure – Spring / Hibernate / Ignite for Sakai-21

For those who have been around a long time – or those who read my book about the founding of Sakai, you know how strongly I feel about addressing technical debt in a project like Sakai.

Sakai-21 is coming out in a quicker time scale than usual so we can target a release by the end of the year. This has meant that some things like the all new Lessons got pushed to Sakai-22 – even though Dave Bauer gave us a nice facelift of the existing Lessons at the last minute.

But even in that short time scale some really amazing work has been done on technical debt inside the Sakai code base. Java is still a great choice for web applications – and Java just keeps improving – but we need to keep up to build better features using the latest that Java has to offer.

There are two major things in Sakai-21 that no user will ever see – but are critical to us from an infrastructure perspective:

– Spring and Hibernate have been upgraded to the latest versions – this is the first time we have not been running a “back-level” version of these libraries. It is a lot of work to upgrade these libraries and when it is all done – you just see the exact same Sakai UI as before. But they are essential to give us a strong platform to build upon.

– The cluster coordination has been replaced with Apache Ignite – which is a Redis-like product that does not require a separate server. When a school moves from one to many app servers, somehow these servers need to coordinate things through distributed “caches” – Hibernate uses these caches and things like the authorization service (who can do what to which object?) uses caching as well for performance. Back in 2005 we used the database as a distributed cache – which severely limited our ability to scale. Ignite is fast, efficient, open source and does not require any additional server deployment. (We do need to get it to quiet down in the logs a bit :) ).

Both of these things are very challenging technical efforts that take effort away from things that users see. But these investments are essential to keep our product performing well, based on supported libraries, and make new developments much easier.

As an example, I am adding a cluster-wide cache for the keys used to generate and check OAuth tokens for the LTI Advantage API (SAK-44195) for Sakai-21. This is essential (a) for performance, and (b) so that API calls can be spread across a Sakai cluster for larger schools.

Because of the amazing Ignite work that Earle has done, the following is how you create and use a cluster-wide cache in Sakai:

Ignite ignite = (Ignite) ComponentManager.get(“org.sakaiproject.ignite.SakaiIgnite”);
IgniteCache<String, String> igniteCache = ignite.getOrCreateCache(“blisCache”);

System.out.println(“get=”+igniteCache.get(“42”));
igniteCache.put(“42”, “HHGTG”);

Literally in two lines of Java I create or connect to a scalable distributed key value store in Sakai that just works. This is the magic of what Earle has done in his Ignite project. Take something very complex inside of our code base and reduce it to two lines of code.

Adding this new infrastructure will allow us to remove a lot of cruft from the Sakai code base over the years and really improve the performance and scalability of Sakai going forward and gets us one step closer to our goals for the Sakai infrastructure.

So thanks to Earle and others who built and tested these great contributions to Sakai-21.

Thinking about a license change to GPL for Tsugi

I have been rolling around an idea a switch to GPL as the core license of Tsugi and am curious as to what you think.
This is definitely a switch in direction – the Apereo Foundation (and Sakai Foundation before that) – has historically been very pro Apache (and its second cousin once removed ECL).
I have done some writing over the years that is not particular friendly to GPL:
But I have been GPL-curious for a long time:
Here is my 2020 summary of how we got here and where we might go from here:
– In 2003, GPL felt a lot more like an “infection” – commercial companies were scared to go near it in case the the GPL infection might spread to their proprietary products (i.e. like in the Ring movie – if you look at GPL code you are forever marked).   IBM built staffing firewalls where those who touched GPL code never interacted with “real” IBM engineers.
– Because of this, there was a notion that if you did GPL, companies would neither adopt nor help you.  Hence Sakai was militant pro Apache in 2004.
– In the by 2008, we kind of understood that modern companies were not afraid of GPL.  And frankly if a company was afraid of GPL – perhaps that was an indication that the company had a slightly different set of values w.r.t. open source.   And it turns out that one company back in 2004 that was the most vocal against GPL *did* have some big plans that were not entirely shared with us.  Thankfully that company is no longer in existence – due in part because their strategy was not as profitable as they had hoped :)
– In the early days, when we spent a lot of time “transferring copyright ownership” to the Foundation, using the Apache / ECL license felt better to a lot of folks.  But for “organically grown” code like Tsugi – and the new github world where collaborators flow in – it really does not matter.
If you look at my most blistering attack on GPL:
It is less an attack on GPL per se and more an attack on “who owns copyright”.
What has happened in the past decade is a change in approach to copyright “ownership”.  In the old days, Apache and Sakai/Apereo transferred “ownership” of the code to the Foundation.  And for the early part of Moodle – Martin Dougiamas owned all the code and any contributions were given to him.
Things are different today.  The Apache Foundation and Moodle lets contributors keep the copyright on their contributions and simply provide a non-expiring no limitations right to use.
This means that Moodle is no longer 100% owned by Martin.  It might be 80% owned by Martin (legacy) but 20% is owned but other people.  It is 100% *licensed* to the Moodle community and those licenses cannot be revoked.
This is a super important distinction as it has to do with the danger of someone like Martin or the Apereo Foundation going evil and selling their interest to some third party.   Yes this is unlikely that Apereo will go evil – but if there was a complete turnover of the board – we Apereo could quit-claim their interest to some proprietary company.
But with multiple “owners” like Moodle has, Martin can only “quit claim” 80% of the code.   The other 100 or so contributors also need to quit claim.  This effectively insures Martin can’t really do a meaningful quit claim.
Once the “who owns the code” and “who works on the code” is resolved – the difference between GPL and Apache is that GPL is harder to fork and go proprietary.  It is trivial to fork and go open source.
And the key *advantage* of GPL is that GPL is seen as an “activist” open source license.  Apache is pretty passive – there is little brand value to being Apache.  The Apache brand is about being very boring.  There *is* brand value being GPL because of the Free Software Foundation’s promotion of your product:
Sakai and Tsugi are not “open enough” to qualify as software that protects user freedom.
This might seem insignificant – but if by switching to GPL – we gain marketing and lose nothing – then why not.
Thoughts welcome.

Styling Tsugi / Koseu Lessons

I am developing a version of Lessons that can be heavily tweaked through CSS.  To do this I am revising the HTML output of Lessons to be more basic and semantic and therefore more easily tweaked by CSS.  The new default look and feel of Lessons looks like this (go into a lesson):
You can see some examples of how you can tweak the look and feel here (go into a lesson):
First you will notice that the carousel is gone.  It is actually not exactly gone – but if you put “videos” in a module it renders like the above two sites.  You can go back to the carousel by changing all of the “videos” keys in your lessons.json to “carousel” and poof the carousel will reappear.
There are two new features in lessons.json – take a look:
"headers": [
    "<link href=\"{apphome}/css/lessons.css\" rel=\"stylesheet\">"
],
"settings": {
    "prev-next": "right"
},
The headers is an array of text lines to add the the <head> part of lessons pages.  The {apphome} expands to the top URL for the site.  You can do a bunch of fun stuff here.  I load up some CSS.
You can see that I have added some classes to the tags in the Lessons module output that should let you get a handle on the markup and tweak it.
In my lessons.css I add a image based icon and a fontawesome based icon as well as tweak the list styles.
There is also a new settings area that allows us to tweak the UI here and there.  The first setting is whether you want the prev/next aligned right or full width.  The useful values for this are “right” and “full” – the default is “full” as you can see on WA4E.
This is a start to provide more options and a lot of flexibility without requiring a bunch of code changes every time folks want things to look different.

Django For Everybody – Autograder Server Outage

We are just over a week into the Django for Everybody Specialization and we have a server outage. This server outage affects all of the autograders which run on a server outside Coursera – (www.dj4e.com). This is *not* a problem with the Coursera servers this is my server.  Coursera servers are doing just great.

The outage may last as long as Sunday 5PM Eastern United States Time.

When I saw the server down today Friday at 5PM, I figured that it was because the crush of students in DJ4E had overrun it with all of their enthusiastic load. And then I realized that it has plenty of performance to spare – but instead it was in a server room where the electric company is re-doing the power into the building this weekend. So it will be a while.

Once the server comes back up – I will move this server to our Amazon hosted systems. These systems are still University of Michigan operated and professionally maintained and care deeply about protecting your private data.

When I taught this material on campus, it was fine to run this course using our on-campus resources, but before we released this as a world-wide MOOC – I should have moved the server from UM on campus resources to UM Amazon resources. Once the server comes back up I can do that move in less than an hour and with no loss of data. I won’t do that right away – when it comes back up – I will just leave it alone for a bit and then migrate to a new server room after things settle down.

So I apologize personally for this outage and will make sure to keep such an outage from happening in the future and once this comes back up we can all get back to learning Django.

While you are waiting, you can binge-watch all of my office hours or my car racing playlist on YouTube:

https://www.youtube.com/playlist?list=PLlRFEj9H3Oj6VbnK4nrBt5p803kXnf6VT

https://www.youtube.com/playlist?list=PLlRFEj9H3Oj4qyq0OLZ76cMtUUgqUNtmz

Thanks for being part of the first week of Django for Everybody.

Sakai Racing Team – 24 Hours of Lemons – RustBelt GP 2020

This is a summary of the Sakai Racing Team at 24 Hours of Lemons – RustBelt GP 2020 race this past weekend (July 26-28).

https://www.sakaiger.com/sakaicar/

It was a furious two weeks of preparation before the race that  led to an epic all-nighter Wednesday night before the race.  Neon 2 (2.0 DOHC) had been running smoothly for over a month after the engine replacement but that was not the car we wanted to run.   We tend to get in trouble because of its soft suspension so we want to run a Neon with coilovers and the 2.4L engine swap (Neon1 or Neon3).

Neon3 had the Independent Throttle Bodies which were 100% custom – so every little bit of the setup was custom – making and debugging a custom fuel rail took about a week and a half.  I spend the last two weeks painting body panels for Neon 3 so it at least looked like a Sakaiger.  We knew it would be close.

Since Neon3 was too close – Scott and Chris started working furiously on the stalling problem in Neon 1.   The car was running great except it would stall after 5-20 miles and not restart for 20-30 minutes – then start right up.  We had checked everything – we put a 100% rebuilt wiring harness into the car – and still intermittent stalling.  For the two weeks prior to the race we would test run it with a chase car and then try to guess what went wrong.

On the  last weekend before the race we zeroed in on the O2 sensor setup – we only had hooked one up and had put it into one of the header tubes.   So we installed two new bungs in the header collector, so we could put both the upstream and downstream sensors in.  Once that was done, Scott and Chris discovered that the new wiring harness had put an upstream connector on both the upstream and downstream wires.  Then since the sensor moved about 18 inches further toward the back of the car, the (very high temperature) wiring needed to be extended.  Also running with a missing O2 sensor had caused it to lean out and the sensors themselves were cooked – and we did not have time to get new ones.   So some adaptation was done – taking more time.   Wednesday evening it started working and about 10PM I heard a loud engine pull up to my house.   Scott had driven Neon1 20 miles to my house with Chris in the chase truck and it had no problems.  They went back and wrapped things up – I got my last email of the night from Scott at 4:38 AM:

The oxygen sensor and new injectors cleaned up the air fuel mixture problem almost entirely. The car runs much better with far more power, smoother acceleration, idles better and the air fuel stays in range. I drove it hard around the block and it never showed dashes. I am removing it from double secret probation. Not a totally clean bill of health but very close. Chris is going to work on a thermostatic fan switch in the future. For now no extended idling. So it was late when I dropped the T-trailer off at Jake’s. I forgot the tie down straps. We should drop them off in the morning.  I also need to pick up a tire from Jake that I dropped off for him to work on clearance. Neon 1 currently has one mismatched wheel. We need to load tools for tire changes and other stuff in the morning. We need to load tents and stuff you want as well. We need to load 4 gas cans for neon 3 so Jake can tune it on 93 octane. After he is done we could put on 100 or 110 octane from the track and see what Jake can tune it to if we wanted, Meh. I picked up the trailer at Doc’s and forgot to drop off some parts for him. We could/should drive by Docs and pick up your Grand Prix. Drop your Volt there and we will trade back when we return. I would like to drop some parts in the back of the truck off at Doc’s as well. I say get here fairly early. Load up go to Jake’s then Doc’s then head down 94 to Gingerman’s or Lane’s or whatever. Shoot for 11 to 12 am arrival at Gingerman. Maybe earlier.
I do not think Jake will have Neon 3 ready at noon or until I get there and discuss the fuel problem with Jake. He is missing the clip on the top of the fuel injector that clips to the fuel rail. I will have to machine a slot in the rail and grind two tabs off a bunch of clips I have hanging around and use these clips to hold the injectors to the fuel rail with a death grip. I just realized I never dealt with a rail that did not have these clips. There is 50 PSI above each of four injector totaling over 1 square inch of surface area. There could be upwards of eighty pounds of total force upward on the fuel rail and zip ties and plumbers tape will not cut it in that application.

So Wednesday morning we had a running Neon1 in the trailer and started our journey.  First we took a look at the fuel rail problem with Neon3 – by the time we got there, Jake had solved it with aircraft-grade stainless steel tie wire.   But Jake was waiting for some JB-weld to seal up some pin-holes in the radiator so it would take about an hour before Jake could start the car.  Also the fire suppression system was totally discharged so we needed a new one.

So Scott and I took off for Gingerman with Neon 1 in the trailer and me driving the Pontiac GXP in hopes that I could get to Lane Automotive and buy the fire supression kit and then Scott and I would meet at Gingerman for the track day.  Lane had one fire suppression kit so I bought it and made it to Gingerman around 2PM.

We pulled Neon 1 out and started running it in each of our 20 minute track slots.  It ran great.   Fast, sticky.  Scott was timing me and I set a new team lap record at 1:58 – of course having so few cars on the track helps lap times.

Mid-afternoon Jake texted and said that Neon 3 had started and run great – and they finally got to 178HP at the wheel – and the transmission ate its own lunch – so Neon 3 was off the table and Neon 1 was our only hope.   But all day Thursday Neon 1 ran excellent so we thought our stalling problems were behind us.

I developed a driving technique where I decided to see how well I could run without leaving fourth gear.   You lost a touch of pop coming out of turns – but I just started accelerating earlier and I set my own personal best lap time driving with only one shift into fifth on the back straight – the rest of the lap I would just use 4th as if it were an automatic.   The nice thing is that when I was using 3-4-5 the water temp got up to 220 and if I did the 4-5 only the temp stayed around 200.   Since overheating was the cause of all of Neon 1’s catastrophic failures – I made a team decision that we would “use the fourth” as a driving approach to save the car so we could finish a complete race.

Friday morning was a Lemons track day and Greg and Mark each got stints in Neon 1 that went flawlessly.  So we retired early (no bars because Covid) and got a decent night’s sleep for Saturday morning start.

Saturday morning we let Greg start the first run.  He ran great – car ran great – several sub-2:00 laps – this time with traffic on the course.   After about 90 minutes Greg came in because he felt that a tire was letting go – which it was so he came in and we put on new tires.  When we put Mark in to go back out, the starter was dead – sheesh.  We had to teach him how to pop the clutch to start the car and sent him out.  After about 30 minutes, Mark called in on the radio – he was dead on the side of the road and needed a tow.  The stalling gremlins were back.

By the time Mark was towed in the car again started perfectly.  We decided that we might just give it another try – the O2 sensors were looking really good and it ran great.   So I suited up and went back out.  After 1.5 laps I was on the side of the track stalled again.  I was on the inside of turn 10 well off the track and it was a great place to watch the action in a fire suit + cool suit + roll cage.  All the cars were accelerating on the backstretch so I saw a lot of good racing.

When I finally got towed in, we called Scott (who was already driving back to Jackson to get more tires) to bring Neon 2 back to the track.   He decided the quickest way was to drive Neon 2 back to the track – he did not have a GPS so he got lost and got back around 3PM.  Interestingly Neon 2 had a nice set of tires so we got another set of tires as well.

When Neon 2 arrived, we put Matt in the car.  He went out and started doing laps.  After about an hour he got in a wreck caused by another super aggressive driver.  He had to come off for an inspection but things looked good – so we sent him back out to finish the race for the day.

About 15 minutes before the end of the race, Matt called in – something let go and oiled the track in turn 1 and about five cars spun off the track.   It was such a mess that they stopped the race 15 minutes early.  We assumed that it was a another thrown rod.  But after he came in and things cooled off – we realized the transmission blew up.  The engine started and ran perfectly.

That was weird – two (quite reliable) Neon manual transmission failures within 24 hours.

At the end of the first day we were shell-shocked.  The day had started so optimistic and just like last October by the end of day 1 – we had one car with stalling problems and one car that had a hole in a part “where the rain came in”.  We just sat around and had a beer – it looked like we were packing up at the end day 1 and going home for the second time in two races.

Scott brought a starter from home – we installed it in Neon 1 and no start – so we took the starter out of Neon 2 and it did not fit.  Then we tested the starter we took out of Neon 1 and it was fine but when we tested the wires the voltage seemed wrong – so we started back tracking – checked all the fuses – and replaced a starter relay from Neon 1 and then just fiddled with how the wiring was hooked up and then it started.   We fiddled so much that we have no idea what actually fixed it.

Then we started to think more about the stalling problem and came up with three hypothesis:

– I pulled the codes and saw a (P1493) battery hot code – it said that the ECM detects hot battery and slows charging.  Interestingly we did not have a battery sensor because the batter was in the back.  But it threw a code anyways.  Which was weird.

– I was sending OBD data to a live web site and Greg wondered if the OBD reader (Carista) was overheating and confusing things

– Greg also had a problem in another vehicle he owned where he had a marginal battery with an internal structural problem that would bounce and  momentarily short inside the battery killing the engine

– Scott had brought back the original Syked ECU – so we swapped ECUs as well

So we decided that we would remove the Carista, find an temp sensor, plug it in and zip tie it somewhere there was cool air and swap batteries with Neon 2.

We drove home Saturday night, with Neon 2 in the trailer, and dropped it off at the transmission shop at midnight, then got to Scott’s about 12:30 and I went home.  While I was driving Scott figured out that the temperature sensor was not likely to be in stock anywhere – but it might be at the O’Reilly store in South Haven.  But he also woke Chris up at 1AM to look at the Mitchell’s and figure out how to make a fake sensor from a resistor which he decided that a 10K was the right choice.  You can’t buy resistors in a store any more (sad to see Radio Shack go) – but Chris had one in stock.

So bright Sunday morning at 7AM – Scott went and got a resistor and drove two hours to the track.  I drove to the O’Reilly’s and found they did not have the temperature sensor.

We go to the track, installed the temperature sensor override resistor and removed the Carista.  We also quickly installed the cool suit pump / reservoir since it was going to be a really hot day.

We sent Matt out and he drove for the morning session from 9:30 – 11:00. And the car ran great – but about 10 minutes before the end of the session – the exhaust got really loud and Matt came in.  We had lost all the bolts from the header to the the exhaust pipe. I borrowed some grade 8 bolts from a neighbor and we had the car back together about 11:30.

Still during the 11-12 break, Scott and Matt changed the camber because we kept wearing the insides of the tires.  Why we did not do this earlier I will never know.

When the race restarted at noon, I went out – I loved the new camber and was doing solid laps and having a great time.  I drove for about 90 minutes and then came in for a driver change to Mark.   Mark drove for about an hour and we came in for a driver change and let Scott drive about an hour and take the checkered flag.

Normally during the last driver shift we start to pack up all the stuff – but we were just so worn down from all the changes / failures of the past three days, we just relaxed and counted down the last few laps.

It was a heck of a weekend – I was so bummed at the end of Saturday – I wondered if we should just give up racing all together.  But at that same moment – we might have brought all our minds together and solved the “ghosts in the wires” of Neon 1.   So Saturday was the worst of times and Sunday was much better times.

We need to replace the transmission in Neon 2.   I think I will put coil overs in Neon2.  Neon 2 needs body work – which I will get done.  We will take Neon 1 to every track day we can and drive the crap out of it – to see if we can get it to stall again.

My hope is to have Neon 1 and Neon 2 race ready.  I am starting to think that Neon 3 will never see a Lemons race – because it is too “one-of-a-kind” and I won’t be willing to have it wrecked.   So it might just be my track-day show-off toy.

 

Email Answer: Can I translate Python for Everybody?

I really enjoy getting my cup of coffee in the morning and composing a letter to someone who has inquired about translating my Python textbook.   Here is how it goes.

Nice to meet you,

I agree with you that it is important to translate introductory materials to a students own language and want to support translation efforts in every way I can.

I have written a document that captures most of the details of translation the book and course materials:

https://github.com/csev/py4e/blob/master/TRANSLATION.md

The simple answer to your licensing question is ‘yes’  – everything in my github repository except the book is CC-BY.  Electronic copies of the book are CC-BY-SA because of the prior copyrights of the materials I used to build the book.  Print copies of the book are CC-BY-NC – which means the only thing that you need permission from me is to sell print copies of the resulting book which I will give once I see that the translation is complete and of high quality.

Simply charging credit for the courses does *not* trigger the NC clause.   You are welcome to use my materials and charge for the course.  You could even print the book and sell it at cost of printing (no profit) if you like.

So that should give you the permission that you need.  But how these translations usually work out is that they become a collaborative effort with me providing some technical assistance for things like automatic generation of the book files, help getting the book on Amazon, help making a new translated cover for the book,  help getting the book on Amazon, and even hosting a web site like https://es.py4e.com if the translation goes beyond just the book.

So you have my permission – but in addition you have my offer of help, support and promotion of your work.

I look forward to seeing your translation of our book.

Charles Severance