Category: AI, Computation, and Technology

  • STATE OF THE CODE (SO TO SPEAK) ( I can see I’m my writing and in my code and in

    STATE OF THE CODE (SO TO SPEAK)

    ( I can see I’m my writing and in my code and in my business thinking that my recovery from burnout is nearly complete. I can almost stay in the flow now without concentrated effort. And I am able to construct novel insights again. )

    I will have to do a lot of refactoring of the code. Small things make terrible impact. In our case the team apparently feared data driven functionality because of the automated tools they were using to script database changes. They also became dependent upon the data table api to the point where it’s a constant performance liability. They did these things out of expediency. But in the end it became a prison. I couldn’t understand why simple things were taking so long and now I can.

    Secondly, all methods and properties of the classes are public. This might sound small but it makes the code far harder to read. The object oriented-ness of the code is a chimera. It’s really just libraries written functionally, not objects.

    Third, let me help programmers and tell you that ORM’s are good at helping you with production work but not with complex data sets – especially large ones.

    – Use views or procedures for anything with nondomain ( semantic ) joins.

    – Use triggers to demormalize data.

    – Use the ORM’s for updates and deletes. Always use prepared ( parametrised) queries.

    – Fetches are memory expensive and user performance sensitive.

    – If you are making an in-query then you should almost always be data driving instead.

    Fourth, I have just lost all faith in MVC unless code convention enforces the relationship between the physical and the logical. Codeigniter did this better than Laravel does. Sometimes syntax is expedient at the cost of traceability.

    Fifth, the JavaScript code is far better than the backend code. But the backend developers understood the business rules far better. So it is visible that there is a disputed between which code should own what responsibility and the back owns too much.

    So you have this incredibly sophisticated and fast application but the code is extremely difficult to maintain and extend.

    There is CSS on the back end. There are hard coded properties and relations that should be in the database. There are no means of identifying the origin of resulting DOM entities. So basically everything is inconsistently written and impossible to follow.

    ***Fixing it***

    How do you fix it? One route ( api call ) at a time. You replace each method in sequence.

    For example: most program logic is dependent upon a small set of tables that contain things like the properties of the task entities. This data should be read and kept in an application store in memory and addressed as an object and re-queried upon change – when needed for code, but still available for joins when in the database.

    There seems to be little database relation between stages and states. And this should be reinforced.

    Why? Data drive. Apps are self-documenting and force authors to work in sets using arrays.

    ***Build Process and deployment process.***

    At some point there was an effort to use gulp and it was incomplete. At some point scss and incomplete. The Dev build was never created and took me the better part of five days to reproduce.

    ***what are we doing now***

    ROMANS TEAM

    Romans team is adding the recruiting features. The entities exist but the properties don’t.

    They are also working on bugs.

    They are also training our first client of any size.

    CURTS TEAM

    -Roman(my roman) is now creating a proper build and environment.

    -Vasiliy is creating a proper deploy.

    -I am adding the auction features.

    -I will task the front end guys with minor front end work until they get a feeling for it. And once they do I will get one of them to work on extending the Gantt, and the other on the Usability issues that remain.

    – I will see if Vasiliy can correct the Commands ( artisan ) allowing us to maintain the app more easily.

    – the majority of the work will fall to me for the workflows ( relatively easy ) and Roman for the payment system. I suspect I will also extended the “money tabs” and possibly consolidate them into one.

    Lesson? In starting this project I wanted to limit myself to desig and PM work so that my time was split with writing. I thought that between the framework, the UI screens, the database design, and light pm, it would allow me to stay out of the code once I had a crew sufficiently trained.

    I was wrong.

    But since the purpose of this work was to fund my writing, my choice would have been either not to do the work, or to cancel it when I hit my minimum cash over a year ago.

    But I’m reasonably happy with the result. The product rocks. It needs some work, sure. But it freaking rocks.

    So I’m going to take a cue from Matt Mullenweg, and my trusted (unnamed) marketing advisor from Seattle, and stay deep in the code. At least until it’s no longer necessary.

    I have to do the following to get us to done with my vision for v1.

    TO DO:

    Improve the auction features to send out additional notifications.

    I am contemplating just extending the skills functionality to act as a general filter for the auctions ( for auction work ). The seems like the smartest thing to do. But I will have to add other controls to the skills panel and rename it or create an additional panel for other controls ( which doesn’t feel right – tags are tags are tags so to speak.

    Integrate with WordPress. This will make the Jira/confluence model obsolete. The same way we have made Jira workflows obsolete.

    Create the dashboard for managing business cycles : time cards, forecasts, accounting periods.

    Extend the money tab to include the new accounting entries.

    Extend the approval tabs to include the new entities.

    Complete the standard reports.

    Improve invoicing to accommodate new financial relations.

    Add the personality surveys and reports ( exciting ).

    Add the import functionality for migration of customer data.

    Create the API for external systems.

    Refactor the code for clarity and performance. ( this will be an ongoing process )

    That’s v1 that satisfies the community free-to-use model, the in house platform, and freelancer community platform.

    Thanks for listening.

    -Curt


    Source date (UTC): 2016-06-19 06:40:00 UTC

  • We started with Babbage’s gears, and arithmetic. We moved to switches and numeri

    We started with Babbage’s gears, and arithmetic.

    We moved to switches and numeric codes and formulae.

    We moved to vacuum tubes and assembly language and programs.

    We moved to transistors and short code language and operating systems, and hierarchical databases.

    We moved to chips of transistors and human readable language, and networks, and binary communication, and relational databases.

    We moved to networks of systems, human-readable documents, distributed networks and string communication.

    We move to browser-as-operating system, and virtualization, and the storage of documents as databases.

    Then to the browser-as-operating system on both client and server, using documents to transfer information. And we have begun experimenting with human language commands.

    We have slowly replaced the mechanical, with the binary, with the string, and finally the document.

    And we have taken the browser’s string-operating system,

    And we have transferred the browser’s string operating system to the server.

    We are slowly approaching where a command consists of the evolution of a ‘document’ (context), iteratively constructed from human language, then submitted as a query to a network of documents, in search of an answer stored as similar documents and indexed as relations.

    The original authors of Lisp should be proud because while more expensive, it was they who were on the right track. But like many competitors, a superior technology (lisp/betamax) could not compete with a less costly one(c/vhs).

    And when that happens a generational leap of significant value is required to correct the prior ‘error’ made by ‘rational’ market choice.

    You see, google is actually inhibiting the evolution of artificial intelligence. Honestly. Why?

    Because their monetary incentive is to provide you with inaccurate results that you must humanly parse – or they would have no opportunity to advertise, except by interrupting you.

    So google will be put out of business by document-context searches the same way that view-ad-to-access video has failed.

    What we need is to construct a document (query) with enough context to return the question that we’re asking. When that happens there will no longer be an opportunity to advertise. Why? Because someone will come along and offer access to ad-free searches for a few dollars a year, leaving google as the search engine of those without money.

    (And yes we were working on this back in 2007)

    Cheers


    Source date (UTC): 2016-06-19 04:01:00 UTC

  • Tech Progression

    We started with Babbage’s gears, and arithmetic. We moved to switches and numeric codes and formulae. We moved to vacuum tubes and assembly language and programs.

    We moved to transistors and short code language and operating systems, and hierarchical databases. We moved to chips of transistors and human readable language, and networks, and binary communication, and relational databases. We moved to networks of systems, human-readable documents, distributed networks and string communication. We move to browser-as-operating system, and virtualization, and the storage of documents as databases. Then to the browser-as-operating system on both client and server, using documents to transfer information. And we have begun experimenting with human language commands. We have slowly replaced the mechanical, with the binary, with the string, and finally the document. And we have taken the browser’s string-operating system, And we have transferred the browser’s string operating system to the server. We are slowly approaching where a command consists of the evolution of a ‘document’ (context), iteratively constructed from human language, then submitted as a query to a network of documents, in search of an answer stored as similar documents and indexed as relations. The original authors of Lisp should be proud because while more expensive, it was they who were on the right track. But like many competitors, a superior technology (lisp/betamax) could not compete with a less costly one(c/vhs). And when that happens a generational leap of significant value is required to correct the prior ‘error’ made by ‘rational’ market choice. You see, google is actually inhibiting the evolution of artificial intelligence. Honestly. Why? Because their monetary incentive is to provide you with inaccurate results that you must humanly parse – or they would have no opportunity to advertise, except by interrupting you. So google will be put out of business by document-context searches the same way that view-ad-to-access video has failed. What we need is to construct a document (query) with enough context to return the question that we’re asking. When that happens there will no longer be an opportunity to advertise. Why? Because someone will come along and offer access to ad-free searches for a few dollars a year, leaving google as the search engine of those without money. (And yes we were working on this back in 2007) Cheers
  • Tech Progression

    We started with Babbage’s gears, and arithmetic. We moved to switches and numeric codes and formulae. We moved to vacuum tubes and assembly language and programs.

    We moved to transistors and short code language and operating systems, and hierarchical databases. We moved to chips of transistors and human readable language, and networks, and binary communication, and relational databases. We moved to networks of systems, human-readable documents, distributed networks and string communication. We move to browser-as-operating system, and virtualization, and the storage of documents as databases. Then to the browser-as-operating system on both client and server, using documents to transfer information. And we have begun experimenting with human language commands. We have slowly replaced the mechanical, with the binary, with the string, and finally the document. And we have taken the browser’s string-operating system, And we have transferred the browser’s string operating system to the server. We are slowly approaching where a command consists of the evolution of a ‘document’ (context), iteratively constructed from human language, then submitted as a query to a network of documents, in search of an answer stored as similar documents and indexed as relations. The original authors of Lisp should be proud because while more expensive, it was they who were on the right track. But like many competitors, a superior technology (lisp/betamax) could not compete with a less costly one(c/vhs). And when that happens a generational leap of significant value is required to correct the prior ‘error’ made by ‘rational’ market choice. You see, google is actually inhibiting the evolution of artificial intelligence. Honestly. Why? Because their monetary incentive is to provide you with inaccurate results that you must humanly parse – or they would have no opportunity to advertise, except by interrupting you. So google will be put out of business by document-context searches the same way that view-ad-to-access video has failed. What we need is to construct a document (query) with enough context to return the question that we’re asking. When that happens there will no longer be an opportunity to advertise. Why? Because someone will come along and offer access to ad-free searches for a few dollars a year, leaving google as the search engine of those without money. (And yes we were working on this back in 2007) Cheers
  • OVERSING UPDATE. I’m working on a feature that Max originally recommended: aucti

    OVERSING UPDATE.

    I’m working on a feature that Max originally recommended: auctioning work.

    So you can take a ticket/task/story/deliverable, and set the skill requirements. And then publish it to the market, where people can bid on it.

    You can view bids, and accept them or not.

    Likewise you can search the market for work and bid in it if you have the skills.

    The workflow designer has a stage (column) type of market. Anything in a market stage is visible in the market.

    Got it working. Now I’ve got to make it beautiful. ;). Thankfully our designer has done good work.


    Source date (UTC): 2016-06-17 23:07:00 UTC

  • What kind of person writes a zillion line program using templates without giving

    What kind of person writes a zillion line program using templates without giving id’s to elements, or using classes as ids? OMFG.


    Source date (UTC): 2016-06-16 09:22:00 UTC

  • OVERSING UPDATE (mostly back on my feet again) Roman and the guys are importing

    OVERSING UPDATE

    (mostly back on my feet again)

    Roman and the guys are importing data and bug fixing at our first major client. The client says it’s going well. I’m certainly excited.

    Today

    1) My team is trying to understand the system so that we can add the new panels for ‘auctions of work’ so to speak, and searching for talent to do work. Right now you search primarily by skills and availability. But we want to create the option to search without concern for availability, and to show the profile first, and the schedule only if wanted. Why? Because freelancers and contractors are a major part of the creative and technology industries. And when you resource your staff you try to increase utilization (schedule driven) and when you resource contractors you have a larger pool of candidates to draw from that would make schedule driven user interface challenging.

    2) Moving us off of some ‘custom’ build code and onto contemporary build processes. I’ve wanted this for two years. Finally got it in just a few days of work.

    3) Trying to unwind the mixture of js/php/html/css that seems to have crept in some places (omg you gotta be kidding). We are also running into a terribly difficult problem optimizing the javascript. Our original design loaded only js that was needed. But today we need to optimize by condensing it. This is going to take quite a bit of incremental effort over the coming months.

    4) Someone has allowed another javascript bug that’s sent the browser into constant leaking.

    5) Me, I’m writing the project plan, the stories, working on minor presentation bugs, and adding the new financial entities to the product.

    Cheers


    Source date (UTC): 2016-06-16 04:20:00 UTC

  • OK. Software that mixes HTML, JS, and PHP, and some of the elements are injected

    OK. Software that mixes HTML, JS, and PHP, and some of the elements are injected by js…. I want to kill myself. Who does this sh…t? omg


    Source date (UTC): 2016-06-15 12:18:00 UTC

  • OVERSING UPDATE We launched our first two major beta customer’s on the Oversing

    OVERSING UPDATE

    We launched our first two major beta customer’s on the Oversing Platform this week. Roman and I are devoted to one beta site each. I suppose maybe we could handle a third but that’s probably our limit. We can’t name names, of course, but we’re shaking out the bugs in the real world environment now.

    It’s fascinating to watch people get blown away by Oversing.

    Still have one Javascript feature I can’t seem to tackle – mostly because I can’t afford a month to devote to it.

    We designed oversing so that we could process charges, invoices and payments by program (project). But for my site, we’re upgrading the financial features to process transactions at the Deliverable, Story, Task and Subtask levels. (I should have done it this way in the first place really, now that I realize it).

    So we’re activating:

    a. Lead Entity Type Allow salespeople to open and work a lead.

    And we’re adding:

    b. Deal Entity Type (Bid Submit/Invite) (for Project, deliverable, story, task, ticket) Allow users to place bids on Work, (project, deliverable, story, task, ticket)

    c. Sub-Contract Entity Type (with multiple subtypes – for various sub agreements at the project/task level)

    d. Escrow Entity Type (For deliverable, story, task, ticket)

    e. Invoice Entity Type (for bid entity type)

    f. Payment Entity Type (for bid entity type, or Escrow Entity Type)

    g. Receipt Entity Type (for Payment Entity Type)

    So if you manage a lot of subcontractors or freelancers oversing will make it easier to pay these folk.


    Source date (UTC): 2016-06-11 03:41:00 UTC

  • Wow. I get what Tim B-L is going to do with the internet. Endpoint invisibility.

    Wow. I get what Tim B-L is going to do with the internet. Endpoint invisibility. Content replication. Financial transactions.

    Awesome.


    Source date (UTC): 2016-06-08 02:31:00 UTC