4 ms·

"For developers, that means integrating with individual schools on a one-to-one basis, and that just doesn’t scale" sadly, it still means this exact thing for

"For developers, that means integrating with individual schools on a one-to-one basis, and that just doesn’t scale" sadly, it still means this exact thing for Clever's devs. good luck to them - it's a dirty job, but someone's gotta do it.

hashtree 13y ago
The quote is not true. I've personally done dozens and dozens of integrations, which can/are all be applied to any district. It's actually fairly simple with a functional programming approach, set theory, working with the k-12 companies directly, and if you think of them as data flows. I've taken over for some ex-fb/ex-google, large k-12 companies, vc funded ones... and every single one does it in a really coupled/tangled-mess manner where the statement is actually true (I take over their codebases). If done right, the integrations are a few hundred lines of code (even doing schools, courses, students, teachers, enrollments, grades, standards, etc). The only thing that changes between districts is typically a couple of business rules which are done as filters on the data flow. The unit/integration tests take more lines than the integration. Example integration flow of SIS to LMS: SIS client (pull) <- business rule filters <- integration itself -> business rule filters -> LMS client (push) Example integration flow of LMS to SIS: LMS client (pull) <- business rule filters <- integration itself -> business rule filters -> SIS client (push) Examples of system clients: https://github.com/rockymadden/brainhoney.js https://github.com/rockymadden/brainhoney.js https://github.com/rockymadden/masteryconnect.js https://github.com/rockymadden/masteryconnect.js Example of K-12 specific spec that is often so mangled into most codebases it causes bugs: https://github.com/rockymadden/lti.js https://github.com/rockymadden/lti.js Some I've done (almost a cartesian product): Infinite Campus, BrainHoney, MasteryConnect, Moodle, IFAS, Blackboard, Safari Montage, Edgenuity, netTrekker, PowerSchool, Canvas, dozens more...
templaedhel 13y ago
While this is technically true, unlike our customers, our main job is the intergration. This gives us the benefit of doing some things our customers don't want to dedicate time or money to do. It also gives us a wider view of the systems that are out there (one benefit of having 1/10 USA schools using your product), and allows us to build some really efficient pipelines. For the vast majority of schools their data is syncing with their apps within a few minutes of them signing up. This is something that wouldn't be possible if we had to white glove every new school.
clavalle 13y ago
Not really. Clever basically says "Here is the data that we need" which is basically a handful of simple flat files each covering some aspect of school data. The school is responsible for extracting that data and getting it to Clever (which usually translates into their SIS vendor extracting the data). Luckily most SIS vendors serve many more than one school district so they get the extract done once and all of their clients are covered.

hashtree 13y ago

The quote is not true. I've personally done dozens and dozens of integrations, which can/are all be applied to any district. It's actually fairly simple with a functional programming approach, set theory, working with the k-12 companies directly, and if you think of them as data flows. I've taken over for some ex-fb/ex-google, large k-12 companies, vc funded ones... and every single one does it in a really coupled/tangled-mess manner where the statement is actually true (I take over their codebases). If done right, the integrations are a few hundred lines of code (even doing schools, courses, students, teachers, enrollments, grades, standards, etc). The only thing that changes between districts is typically a couple of business rules which are done as filters on the data flow. The unit/integration tests take more lines than the integration. Example integration flow of SIS to LMS: SIS client (pull) <- business rule filters <- integration itself -> business rule filters -> LMS client (push) Example integration flow of LMS to SIS: LMS client (pull) <- business rule filters <- integration itself -> business rule filters -> SIS client (push) Examples of system clients: https://github.com/rockymadden/brainhoney.js https://github.com/rockymadden/brainhoney.js https://github.com/rockymadden/masteryconnect.js https://github.com/rockymadden/masteryconnect.js Example of K-12 specific spec that is often so mangled into most codebases it causes bugs: https://github.com/rockymadden/lti.js https://github.com/rockymadden/lti.js Some I've done (almost a cartesian product): Infinite Campus, BrainHoney, MasteryConnect, Moodle, IFAS, Blackboard, Safari Montage, Edgenuity, netTrekker, PowerSchool, Canvas, dozens more...

templaedhel 13y ago

While this is technically true, unlike our customers, our main job is the intergration. This gives us the benefit of doing some things our customers don't want to dedicate time or money to do. It also gives us a wider view of the systems that are out there (one benefit of having 1/10 USA schools using your product), and allows us to build some really efficient pipelines. For the vast majority of schools their data is syncing with their apps within a few minutes of them signing up. This is something that wouldn't be possible if we had to white glove every new school.

clavalle 13y ago

Not really. Clever basically says "Here is the data that we need" which is basically a handful of simple flat files each covering some aspect of school data. The school is responsible for extracting that data and getting it to Clever (which usually translates into their SIS vendor extracting the data). Luckily most SIS vendors serve many more than one school district so they get the extract done once and all of their clients are covered.