Различие в мышлении между рабочей станцией и встроенными [закрытыми] программистами

Я понял, что это работает:

exports.Google_EStranslateEN = functions.firestore.document('Users/{userID}/Spanish/Translation_Request_Google').onUpdate((change, context) => {
  if (change.after.data().word != undefined) {
    // copied from https://cloud.google.com/translate/docs/quickstart-client-libraries
    // Imports the Google Cloud client library
    const {Translate} = require('@google-cloud/translate');
    // Your Google Cloud Platform project ID
    const projectId = 'myProject-cd99d';
    // Instantiates a client
    const translate = new Translate({
      projectId: projectId,
    });
    const word = change.after.data().word; // The word to translate
    const options = {
      from: 'es', // the source language
      to: 'en', // the target language
      format: 'text' // HTML vs. plain text
    };
    let translationArray = [];  // clear translation array
    return translate.translate(word, options)  // this return is critical
    .then(function(results) {
      let translation = results[0];
      translationArray.push(translation);
      admin.firestore().collection('Dictionaries').doc('Spanish').collection('Words').doc(word).collection('Translations').doc('English').set({
        translationArray: translationArray,
        language: 'en',
        longLanguage: 'English'
      });
    })
    .then(function() {
      console.log("Write succeeded!");
    })
    .catch(function(error) {
      console.error(error);
    });
  } // close if
});

Ключ должен был вернуть функцию перевода:

    return translate.translate(word, options)

Функция облака также работает быстрее.

Даг Стивенсон ответил на мой предыдущий вопрос :

Вы не возвращаете обещание, выполненное после завершения всей асинхронной работы. Если вы этого не сделаете, Cloud Functions предполагает, что вся ваша работа завершена, и ограничит все ресурсы, а все ожидающие работы будут закрыты.

Обещание, возвращённое translate.translate().then().catch(), игнорируется. Ваш вложенный вызов admin.firestore()...set() имеет похожую проблему. Недостаточно просто вызывать then() и catch() для каждого обещания, потому что then() и catch() оба возвращают еще одно обещание.

blockquote>

Похоже, фраза «вернуть обещание» используется здесь двумя способами. Сказать, что translate.translate() возвращает обещание, отличается от того, что мне нужно вернуть обещание путем кодирования return translate.translate(). Возможно, было бы яснее, если бы Дуг сказал «вернуть функцию» вместо «вернуть обещание»?

Мне также не ясно, нужно ли мне возвращать эту функцию:

[112 ]

Работает одинаково с или без return.

10
задан Benoit 12 February 2009 в 11:47
поделиться

5 ответов

Забавный, что Вы упоминаете malloc () конкретно в Вашем примере.

В каждое жесткое реальное время очень встроенной системой, что я продолжил работать, выделение памяти, управляют особенно (обычно не "куча", но пулы постоянной памяти или что-то подобное)... и также, когда это возможно, все выделение памяти сделано заранее во время инициализации. Это удивительно легче, чем большинство людей верило бы.

malloc () уязвим для фрагментации, недетерминирован, и не делает discrminate между типами памяти. С пулами памяти у Вас могут быть пулы, которые определены местоположение/вытянуты от супер быстрого SRAM, быстрого DRAM, RAM с аварийным батарейным питанием (я видел его), и т.д...

Существует сто других проблем (в ответе на Ваш исходный вопрос), но выделение памяти является большим.

Также:

  • Уважение к / знание аппаратной платформы
  • Не автоматически принятие аппаратных средств прекрасно или даже функционально
  • Осведомленность об определенном языке apects и функциях (например, исключения в C++), который может вызвать вещи уйти в сторону быстро
  • Осведомленность о загрузке ЦП и использовании памяти
  • Осведомленность о прерываниях, вытеснении и последствиях на совместно используемых данных (где абсолютно необходимый - чем менее совместно используемые данные, тем лучше)
  • Большинство встроенных систем является данными / управляемый событиями, в противоположность опрошенному; конечно, существуют исключения
  • Большинство встроенных разработчиков довольно довольно понятием конечных автоматов и поведения/моделирования с сохранением информации
15
ответ дан 3 December 2019 в 13:47
поделиться

Настольные программисты просматривают ресурсы как практически неограниченные. Память, вычислительная мощность, дисковое пространство. Никогда заканчиваемые. Встроенные программисты фокусируются внимательно на всех тех.

О, и встроенные программисты также часто должны волноваться о проблемах выравнивания памяти. Настольные кодеры не делают. Уход о микросхемах Руки. микросхемы x86 не делают.

9
ответ дан 3 December 2019 в 13:47
поделиться

Я настольная среда там является идеей, что "эй я могу всегда выпускать обновление или исправлять для фиксации этого позже". Во встроенном дизайне Вы получаете больше, "это должно работать, вызывают, мы не хотим вспоминать устройство или выпускать еще более длинную программу исправления".

8
ответ дан 3 December 2019 в 13:47
поделиться

2 вещи - как Suroot уже упомянули, после того как Вы выпускаете настольное приложение, это не должно быть "навсегда" особенно в наше время.

Но во встроенном, после того как Вы "поставляете его", это продвигается на Марс, таким образом, Вы не собираетесь быть способными задержать его.

Также одно из существенных различий - то, что встроенные программисты обычно НАМНОГО более сознательны об эффективном управлении кодом и управлении памятью - рабочие столы выполняют ужасный код действительно быстро, встроенный не делает.

1
ответ дан 3 December 2019 в 13:47
поделиться

вопросы размера

8
ответ дан 3 December 2019 в 13:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: