Glen Mazza's Weblog

Main | Next page » Saturday February 18, 2017

Using AppleScript to quickly configure your work environment

At work, I use Mac OS' Script Editor to create and compile AppleScript scripts to quickly configure my desktop depending on the programming task at hand. Each compiled script, or application, I place in the desktop folder so it appears on my desktop and can be activated with a simple double-click.

Three tasks I commonly have that I include and adjust as needed depending on the task:

  • Activating a terminal window with tabs pre-opened to various directories and running various commands. A script that opens up three terminal windows in the specified directories, and optionally runs any commands in those directories, would look as follows (see here for more info):
    tell application "Terminal"
    	do script
    	do script "cd /Users/gmazza/mydir1" in tab 1 of front window
    	my makeTab()
    	do script "cd /Users/gmazza/mydir2" in tab 2 of front window
    	my makeTab()
    	do script "cd /Users/gmazza/mydir3" in tab 3 of front window
    end tell
    on makeTab()
    	tell application "System Events" to keystroke "t" using {command down}
    	delay 0.2
    end makeTab
  • Running IntelliJ IDEA. Simple:
    activate application "IntelliJ IDEA"
  • Opening Chrome with a desired number of tabs to certain webpages:
    tell application "Google Chrome"
    	open location ""
    	open location ""
    	open location ""
    end tell

Script editor has a "run" button allowing me to test the scripts as I develop them. Once done, I save the script both standalone (so I can edit it later if desired), but also export it as an application. Exporting it allows for a simple double-click to directly run the task, rather than bringing up the Script Editor and requiring the script to be run via the "run" button. Monday January 02, 2017

TightBlog 2.0 update...

Happy New Year! I added a new tag management tab to the upcoming TightBlog 2.0 UI, it provides a pageable listing of all tags currently used by a blog, number of entries having that tag, as well as the following functionality:

  • View entries -- see the entries having a given tag
  • Delete tag -- remove a given tag from all blog entries having it
  • Add tag -- add a new tag (or an already existing one) to all blog entries having a given tag (sample use case: wanting to tag all blog entries currently tagged "Java" with the tag "Programming" for those entries not already having that tag)
  • Rename tag -- change the name of a tag to either a new tag or an already existing tag (sample use case: on the basis of a "Java7" tag no longer worth highlighting due to its age, switching the tag to the generic "Java" for blog entries having the former but not yet the latter and just deleting the "Java7" tag for those entries already having the latter.)

I also pulled out the "Planet" functionality in 2.0 (ability to read in, merge and display external RSS feeds) -- not to be mistaken for a home site page such as Oracle Blogs Aquarium or JRoller, that ability will still remain. I'm aware of only one of the fifty or so Roller users currently using planets, and that lone user very halfheartedly. While on the Roller team we simplified the planet functionality about 50%, and in developing TightBlog 1.0 I pulled out about another 50%, but it was still needing 3 database tables and about 3500 lines of code. I felt the effort spent maintaining it would be more productively spent elsewhere in the application. (By way of comparison, the much more utilizable Tag management page requires no extra tables and only about 600 extra lines of code.)

So far, TightBlog 2.0 has fallen to 163 Java class files from the 187 in TightBlog 1.0, making it just under 1/3 the class count of Roller 5.1.2's 493. The removal of the planet functionality dropped the database table count from 17 to 14, nineteen below Roller's 33. My main remaining prerequisite for releasing TightBlog 2.0 is completing the switch from Struts to Spring MVC, as so much of the application is now (Spring) REST API based that including a second web framework as a dependency is increasingly undesirable. Wednesday November 16, 2016

Benefits of Retaining the Electoral College

  1. It respects the Great Compromise between the states - The Great Compromise, meant to protect small states from getting overwhelmed by the larger ones, necessary to get them to agree to form the Union, extended not just to the legislative branch but the executive as well. By adding the equal number of senators to the number of congressmen to determine each state's electoral votes, small states were given additional weighting in the say they would have in choosing the President.

    For example, one state A with twice as much population as B might have 6 representatives to B's 3. However, the number of electoral votes is not 6 to 3 or twice as much say but 8 to 5 due to the addition of the senators, resulting in just 1.6 times as much say, honoring the compromise. Switching to a popular vote would eliminate that weighing benefit, as state A would have roughly twice as many voters as B and hence twice as much say.

    This benefit given to the small states has shrunk by about a third since the country was formed. In the First Congress there were 68 congressmen and 26 senators generating a total of 94 electoral votes, so that a state's population was only a 68/94 = 72.3% factor of its say. Since the number of congressmen was fixed at 435, population now provides 435 / 535 (leaving out D.C.'s 3 electoral votes which aren't based on representation) or 81.3% of the weighting.

  2. States are better protected from voter irregularities occurring in other states - With the Electoral College, any ballot-box stuffing done by one state does not limit the say of others. Take one state with say 10 electoral votes, for example, they could have three, five, ten million falsified ballots for a candidate, they can go to town, it wouldn't matter, only that state's 10 electoral votes would be corrupted. Pennsylvania (20 votes), Iowa (6), Arizona (11), etc., would still have their say and their respective weighting. If we switched to a popular vote, those invalid votes would count to the national total, harming the say of states that run their elections more cleanly. In general:

    • With a national vote election, states which do a better job ensuring valid voting (photo ID, checking to make sure voter registrants are US citizens, alive, etc.) would lose say over states that tend to look the other way in such matters.

    • Conversely, because we use an Electoral College, there is much less incentive for ballot-box stuffing as it doesn't buy one party-dominant states tempted to engage in such activities anything. It results in cleaner elections, and hence a cleaner society, nationwide.

    • A national vote would encourage a race to the bottom in granting suffrage ("State A is now allowing their green card holders to vote, so we should also lest we lose our say...", "State B is now allowing 16 year olds to vote...", etc.)

  3. Close elections are much easier to resolve - The 2000 election between Bush and Gore took about one month to resolve but the focus thankfully was just with Florida and its then-25 electoral votes. Because the Electoral College was all that mattered, the other 49 states could be ignored, 20 inaccurate votes in Idaho for example or 30 missed votes in California could be disregarded. However, if we had a tightly close popular vote election, then every precinct in every county in every state would be subject to re-examination, to grab 5 votes here and 10 votes there because they all count towards the national vote total, not a situation anyone would relish.

  4. With the Electoral College, people are more likely to vote for a candidate based on his/her policies rather than on whether or not he/she has visited their state. - Voters in places like California and Tennessee where the outcome of the vote is not in doubt are perfectly fine with their candidate of choice never visiting their home state during the campaign. More than that, they don't actually want their candidate wasting time in their home states, instead wanting him or her to be in battleground states trying to win them over so their candidate can win. This provides a lot of relief to presidential candidates as it allows them to focus on visiting just 10-15 battleground states, a grueling enough task as it is.

    With a national popular vote, however, it would still make sense to visit vote-rich states regardless of their leanings, causing many voters to get offended if their candidate does not visit them, and possibly switch votes as a result. So the Electoral College is more likely to result in voters casting votes based on the candidate's policies than whether they visited their state, good for the nation as a whole.

  5. The Electoral College makes election night a lot more exciting to watch - A silly argument, but still true. With the Electoral College, viewers see a scoreboard of states that slowly get lit up in red and blue during the evening, for which viewers can celebrate or mourn each time a candidate wins or loses a state. With a national vote you're just waiting for a vote total at the very end, rather dull for all concerned. It would be similar to watching a football game in which all touchdowns and field goals are irrelevant but just the total yards gained within the 60 minutes of play determining the victor.

Finally, it should always be noted that a candidate who wins the popular vote and loses the electoral votes on an election based on the latter wouldn't necessarily have won the popular vote if it were based on the former, as the campaigning done--states visited, TV advertising strategy, issues chosen, voter turnout generated, etc.--is different under the two styles. A skilled candidate who can win with one set of rules quite frequently has the ability to win under another. Wednesday August 31, 2016

TightBlog: August 2016 update

I'm back to work, my summer sabbatical is now complete, so I won't have nearly as much time to spend on TightBlog. The release of TightBlog 1.0 was a mission accomplished for me (similar to my prior time off, which I spent releasing Roller 5.1.) I did get a few simplifications in this month though, removing four more Java source files and 2 JSPs.

I advertised the release of TightBlog 1.0 on the Apache Roller users mailing list and got some more traffic from Roller users who did not yet know of my fork.

I said last month that "talk is cheap" and refrained from mentioning what I'd like to get done. But cheap talk is sometimes still useful: For TightBlog 2.0, I'd like to finish up the REST API for the application, a few more screens still rely on server-side screen generation. Once done, so little Struts code will be remaining that I plan on pulling out the Struts library and replacing it with Struts MVC, whose libraries are already being used for the REST controllers. I hope to get a tag management page in for deleting, renaming, and adding tags. Thymeleaf in addition to or replacing Velocity for the blog templates may also be a good idea. I might remove the Planet functionality as it was seldom used in Roller and the effort spent maintaining it can perhaps better be spent enhancing the rest. Finally, a package renaming and restructuring, replacing the legacy org.apache.roller.* naming with a new org.tightblog.* or similar.

(I still need to convert *this* blog to TightBlog--awaiting the new OpenShift PAAS update before doing so, but maybe I'll switch to Digital Ocean instead...) Sunday July 31, 2016

TightBlog: July 2016 Update

I started a new TightBlog 2.0 branch, with more modernizations and new functionality planned for it. I'd like to list what I have planned, but talk is cheap--let me code and as I am able to complete new features I'll announce them. Just yesterday, for example, I switched to Thymeleaf for email messaging in the 2.0 branch with help from Jose Miguel Samper's article and Daniel Fernandez' sample application. I'm very happy with the results (no more placing HTML tags within Java strings) and expect to see Thymeleaf playing a role in more areas of the application. (A minor retirement, as well--I removed the "all blog" planet as it duplicates the front page theme and can anyway be manually created if desired.)

GitHub is reporting that I'm getting a few more people cloning my work since I announced its release, encouraging to see. TightBlog 1.0 was primarily about getting rid of yesterday's lard (and there was a mountain of it.) While there are still several classes that need refactoring or removal, its foundation is much more solid today, a good base for TightBlog 2.0 to build on. Sunday July 17, 2016

First release - TightBlog v1.0.0 available!

I've found a good point to make my first TightBlog release, and so here it is. I held off on uploading a Java WAR file as TightBlog is primarily for Java enthusiasts who are well acquainted with the concept of mvn clean install and would presumably rely on that instead of any WAR I provided. After the dependencies (Spring, Struts, etc.) are downloaded, TightBlog takes less than a minute to build, and running mvn jetty:run from the app folder afterwards will allow you to quickly demo the application at http://localhost:8080/tightblog.

Some editing enhancements put in over the past week:

  • I pulled out the Xinha rich text editor, last updated in 2010, with the new Quill Editor which I'm downloading to the application via CDN.
  • I added Markdown (specifically CommonMark) as an editing option, giving bloggers now three options (including standard HTML entry) for their blogging pleasure.
  • JSoup was brought in to replace a 2009 script to filter out HTML tags disallowed by the TightBlog admin. Admins are provided six HTML sanitizing options for blog entries (including one option allowing everything), and three for blog comments.

These benefits are in addition to the "Notes" field on the blog edit page (to store metadata about the blog entry) I had added a while back.

Stats: 19 fewer Java source files, dropping me to 187, 62% fewer than the original 493 in the Roller release I forked. 209 issues closed, with eight open for the next release. 85K lines removed, with the removal of Xinha accounting for 15K of that. The GitHub contributors page and the OpenHub stats are indicating that, all told, I managed to drop the code about a third in size, even if I somehow sense I managed more than that. Tuesday July 05, 2016

New user administration functionality in TightBlog

Over the past few days I've added some user administration options to upcoming TightBlog:

  1. Administrators can now require all new account registrants to be approved before they are able to log in. Upon a new registration, TightBlog administrators will be sent emails to either approve or decline the account request, with a subsequent response email sent to the registrant informing them that they can now log in or that their request has been disapproved.

    This option automatically activates email verification--after registration but before the approval routing the registrant will be sent an email to click on to verify ownership of the email account. This provides administrators higher confidence that the person requesting an account with the stated email address is indeed the email address' owner.

  2. Access rights within TightBlog are of two types: Global roles (one per user) and Weblog-specific roles (one for each blog a user has write access to). The former primarily specify whether a user is a regular blogger or a blog server administrator, the latter define the rights a user has for a given weblog: can make drafts but not publish (Contributor), can publish and handle comments and some design configuration (Publisher), or has full ownership of the blog (Owner)--can change the design templates, invite new members, etc.

    I added an additional Blog Creator global role to the Blogger and Admin roles already existing. Admin remains the same while Blog Creator has the former meaning of Blogger. The lone difference between Blogger and Blog Creator is that the latter can create new blogs while the former would need to have someone first invite them to a blog with whichever weblog role the inviter desires. This new option is helpful for administrators who have Contributors or Publishers whom they don't see a need to grant create blog rights, or for blog owners they wish to limit to one, already created, weblog.

    The system administration page allows administrators to choose Blogger or Blog Creator as the default role for new blog registrants, a setting which can be subsequently overridden by an administrator on the User Administration page.

  3. The User Administration page now shows account create date and last logged-in date to help administrators determine dormant accounts that should perhaps be disabled. Friday June 24, 2016

TightBlog: June 2016 Update

Continued work on the TightBlog front-end. While TightBlog is not a single-page app, AngularJS is nonetheless playing more and more of a role on the front end for its two-way binding. Backend, I've updated to Java 8 time as well as upgraded to Struts 2.5. About 60% of the UI is now REST-based. I'm expecting "soonish" to make an testing release that I can place my own blog on while continuing to do front-end enhancements. In particular, I'd like to get the comment management screen more streamlined.

Stats: Eight fewer Java source files, moving me down to 206, 58% less than Roller 5.1.2. 52 JSPs vs. 92 in Roller, but 10-20 more JavaScript files on my side. The simplifications altogether have resulted in about 66.8K lines of source code removed. I'm increasingly running into brick walls in trying to simplify the application further, a good sign that my refactoring work is coming to a close. Nine issues open, with 197 closed. Tuesday May 24, 2016

TightBlog: May 2016 Update

Heavily working on the front-end, moving TightBlog from a server-side rendering with Struts2 & JSPs to a REST-ful architecture. The Spring Framework is doing wonders in allowing me to easily switch to REST API calls, code is nicely melting away in the process. I've mostly finished updating the server admin screens using JQuery and JSRender/JSViews. I'm trying to find a good point right now where I can do a release, deploy my own blog on it, and then continue on with enhancements & refactoring.

Stats: Due to more code auditing and analysis, the issues have jumped up to 20 open vs 177 closed, but most do not need to be done for a first release. Seventeen more Java source files have been removed (actually 20 removed and 3 new ones), dropping me to 214 total. GitHub is reporting I've removed more than 62,000 lines from the project; the OpenHub chart, which sizes the project differently, has noted the project has fallen from about 139K lines of code to 87K since I forked Apache Roller last May. As perhaps a sign of TightBlog's increased modernization, OpenHub is noting the code is 18.9% JavaScript compared to 11% for Roller. Saturday April 23, 2016

TightBlog: April 2016 Update

A satisfyingly productive month. In particular, the blog page rendering system as well as the default blog templates supplied with TightBlog were cleaned out and nicely simplified. At this time, the application is more or less usable as-is, however, I'll be rechecking the data model as well as making an additional pass through the source files to see if I've missed anything.

Stats: Sixteen more Java source files removed, dropping TightBlog to 231 total. From my commit totals, over 55,000 lines removed from the project through 248 non-merge commits. Seven issues open and 157 closed.

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.